This is a "guest diary" submitted by Sally Vandeven. We will gladly forward any responses or please use our comment/forum section to comment publically. Sally is currently enrolled in the SANS Masters Program.
I got to wondering one day how difficult it would be to find the crypto keys used by my browser and a web server for TLS sessions. I figured it would involve a memory dump, volatility, trial and error and maybe a little bit of luck. So I started looking around and like so many things in life….all you have to do is ask. Really. Just ask your browser to give you the secrets and it will! As icing on the cake, Wireshark will read in those secrets and decrypt the data for you. Here’s a quick rundown of the steps:
Set up an environment variable called SSLKEYLOGFILE that points to a writable flat text file. Both Firefox and Chrome (relatively current versions) will look for the variable when they start up. If it exists, the browser will write the values used to generate TLS session keys out to that file.
The file contents looks like this:
64 byte Client Random Values
96 byte Master Secret
16 byte encrypted pre-master secret
96 bytes pre-master secret
The Client_Random entry is for Diffie-Hellman negotiated sessions and the RSA entry is for sessions using RSA or DSA key exchange. If you have the captured TLS encrypted network traffic, these provide the missing pieces needed for decryption. Wireshark can take care of that for you. Again, all you have to do is ask.
This is an encrypted TLS session, before giving Wireshark the secrets.
Point Wireshark at your file $SSLKEYLOGFILE. Select Edit -> Preferences -> Protocols -> SSL and then OK.
To see the decrypted data, use the display filter “ssl && http”. To look at a particular TCP session, right click on any of the entries and choose to “Follow SSL Stream”. This really means “Follow Decrypted SSL Stream”. Notice the new tab at the bottom labeled “Decrypted SSL data”. Incidentally, if you “Follow TCP Stream” you get the encrypted TCP stream.
Wireshark’s awesome decryption feature.
Below is a sample of a decrypted SSL Stream. It contains a login attempt with username and password, some cookies and other goodies that web servers and browsers commonly exchange.
Remember: if you have a file with keys in it and the captured data on your system then anyone that can get their hands on these can decrypt too. Hey, if you are a pen-tester you might try setting be on the lookout for an $SSLKEYLOG variable on your targets. Interesting.
Give it a try but, as always, get written permission from yourself before you begin. Thanks for reading.
This exploration turned into a full blown paper that you can find here:
http://www.sans.org/reading-room/whitepapers/authentication/ssl-tls-whats-hood-34297
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.