Intro
Most IT people are somewhat familiar with Wireshark. It is a traffic analyzer, that helps you learn how networking works, diagnose problems and much more.
One of the problems with the way Wireshark works is that it can’t easily analyze encrypted traffic, like TLS. It used to be if you had the private key(s) you could feed them into Wireshark and it would decrypt the traffic on the fly, but it only worked when using RSA for the key exchange mechanism. As people have started to embrace forward secrecy this broke, as having the private key is no longer enough derive the actual session key used to decrypt the data. The other problem with this is that a private key should not or can not leave the client, server, or HSM it is in. This lead me to coming up with very contrived ways of man-in-the-middling myself to decrypt the traffic(e.g. sslstrip).
Session Key Logging to the Rescue!
Well my friends I’m here to tell you that there is an easier way! It turns out that Firefox and the development version of Chrome both support logging the symmetric session key used to encrypt TLS traffic to a file. You can then point Wireshark at said file and presto! decrypted TLS traffic. Read on to learn how to set this up.
Setting up our Browsers
We need to set an environmental variable.
On Windows:
Go into your computer properties, then click “Advance system settings” then “Environment Variables…”
Add a new user variable called “SSLKEYLOGFILE” and point it at the location that you want the log file to be located at.
On Linux or Mac OS X:
$ export SSLKEYLOGFILE=~/path/to/sslkeylog.log
You can also add this to the last line of your
~/.bashrc
on Linux, or
~/.MacOSX/environment
on OS X so that it is set every time you log in.
The next time that we launch Firefox or the dev channel of Chrome they will log your TLS keys to this file.
Setting up Wireshark
You need at least Wireshark 1.6 for this to work. We simply go into the preferences of Wireshark
Expand the protocols section:
Browse to the location of your log file
The Results
This is more along the lines of what we normally see when look at a TLS packet,
This is what it looks like when you switch to the “Decrypted SSL Data” tab. Note that we can now see the request information in plain-text! Success!
![2015-02-11 22_30_28-_Wi-Fi [Wireshark 1.12.3 (v1.12.3-0-gbb3e9a0 from master-1.12)]](https://jimshaver.net/wp-content/uploads/2015/02/2015-02-11-22_30_28-_Wi-Fi-Wireshark-1.12.3-v1.12.3-0-gbb3e9a0-from-master-1.12.png)
Conclusion
I hope you learned something today, this makes capturing TLS communication so much more straightforward. One of the nice things about this setup is that the client/server machine that generates the TLS traffic doesn’t have to have Wireshark on it, so you don’t have to gum up a clients machine with stuff they won’t need, you can either have them dump the log to a network share or copy it off the machine and reunite it with the machine doing the packet capture later. Thanks for stopping by!
References:
Photo Credit: Mike
Awesome article. Thanks for sharing this tip.
Awsome
I am using Wireshark 1.12, FIrefox 35.0.1 and Windows 7. I can see my SSL/TLS secrets being populated in my log file, but I am not getting the Decrypted SSL Data tab. Any thoughts on what I may be doing wrong?
And you have filled out the “(Pre)-Master-Secret log filename” field in your preferences? Be aware that Wireshark might be sniffing traffic that is not sent by the configured browser, e.g. a background application on the same system might be reaching out over TLS and wouldn’t be logging its keys. It will only show that tab for traffic it can decrypt. Filter out information so that you are only looking at the communication that you are relatively certain is coming from the browser.
I double checked that Wireshark is pointed at the log file. I shut down everything else and used the far side IP address to confirm which traffic I was viewing. I will need to keep digging.
The other thing to mention is that a lot of the data is still either gzipped or binary data like images, so it may appear obscured. But you should still get the tab, in any case.
He did say in the article that “You need at least Wireshark 1.6 for this to work.”. If you are using 1.12, it may not work.
Yeah but I think under their versioning scheme, 1.6 = 1.06 and therefor is older than 1.12.
This guy had the same problem:
https://ask.wireshark.org/questions/30290/decrypting-tls_ecdhe_rsa_with_aes_128_cbc_sha-and-tls_ecdhe_rsa_with_aes_128_gcm_sha256-using-sslkeylogfile
Although he eventually figured it out, he used a slightly older version than yours. Maybe you need to tweak compile options and recompile.
It probably has something to do with forward secrecy. Perhaps it’s not supported in your version. If you visit a site that isn’t using FS:
https://tools.ietf.org/html/rfc5246
You should be able to decrypt this in Wireshark.
Actually it might be the mode of operation for the block cipher that’s the problem. Old versions don’t support GCM. But you are using 1.12…
Thank you for the pointers. I cycled through the security.tls.version.max options as you suggested and confirmed in the captures that the encryption protocol used was changing accordingly. Unfortunately, I am still not getting the Decrypted SSL Data tab, even when going to the IETF site you listed. I found some additional information here http://wiki.wireshark.org/SSL, a “wireshark -v” on my system lists GnuTLS 3.2.15 and Gcrypt 1.6.2. I am using the latest stable version that comes in the Windows installer so I have whatever compile options that it is built with. I will keep digging.
Not sure why the log file doesn’t get populated on my Mac … set the variable:
$ set | grep SSLKEY
SSLKEYLOGFILE=/Users/papaia/SSLkeylogs/sslkeylog.log
and running FF 35.0.1 ???
Yeah I didn’t actually get to test this on a Mac as I no longer own one. Looks like OS X did some redecorating recently with environmental variables see this. Maybe it needs to be a system environmental variable on OS X?
Use “launchctl setenv SSLKEYLOGFILE=~/Users/papaia/SSLkeylogs/sslkeylog.log” instead of export.
Any remotely recent version of Chrome will work just fine now. At the time of the cited blog post (look at the timestamp), the feature was new in NSS had only hit dev channel.
Or use Cloudshark, just drag the key onto the web page and then hit decrypt. Its nice because I can let my IT minions debug pcaps without me giving them the TLS keys to the kingdom!!! Course, Cloudshark isnt free like wireshark even though its based on it
Thanks for the blog entry, much appreciated.
My question is, what benefit would one get by using Wireshark to MitM encrypted web traffic as opposed to BurpSuite? (http://portswigger.net/burp/)
If there is no benefit, then probably BurpSuite is the easiest way.
With Wireshark your not doing an active MiTM nor swapping certificates. If you’re troubleshooting an application that does certificate pinning you might prefer to use Wireshark
s/your/you’re. Sorry, it hurts my eyes as well
Great stuff!
And you got the SSL line or it’s just the tab you can’t see? I didn’t see mine coz I was with a proxy. It seems it encapsulate https in http, so you can’t use it to spy on your mates (in this case, at least). Neither you can use it to see app/malware that use their own conection.
I’d like to be give a practical exemple of how to use it.
Nice post, btw.
Can you think of a way to do the same with a mobile browser? Can’t quite find the same set of options for the mobile browsers.
I tried this on Linux Mint 17.1 and FF 35.0.1, double checked that the environmental variable has been set correctly, rebooted and reloaded this page, but no sslkeylog.log was created. Is a specific Linux distribution needed to make this work?
Is the path that you are pointing at an absolute path that you would have write access to? For example /home/username/sslkeylog.log?
export says
declare -x SSLKEYLOGFILE=”/home/jrv/sslkeylog.log”
where jrv is my username and I have write access. More help would be appreciated.
Hmmm…. I don’t have a (graphical) linux box close at hand. I’ll test in a vm this weekend.