

Decrypting TLS Browser Traffic with Wireshark - WestCoastJustin
https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

======
Animats
That article seems to be a rewrite of this 2012 article:
[http://www.root9.net/2012/11/ssl-decryption-with-
wireshark-p...](http://www.root9.net/2012/11/ssl-decryption-with-wireshark-
private.html)

A SSLKEYLOGFILE environment variable makes Firefox and Google Chrome silently
log their crypto keys as plaintext. What could possibly go wrong?

This 2014 discussion
([https://groups.google.com/forum/#!topic/mozilla.dev.tech.cry...](https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/bu3b9x12c1Q))
says that originally the documentation for this feature said that it was only
turned on in debug builds of Firefox. Then, somehow, it was quietly turned on
for all builds, with no notification.

Take a look at the code in Firefox for this:

[https://hg.mozilla.org/projects/nss/file/65605e800fd1/lib/ss...](https://hg.mozilla.org/projects/nss/file/65605e800fd1/lib/ssl/sslsock.c#l2840)

Firefox understands several suspicious environment variables: SSLBYPASS,
SSLKEYLOGFILE, NSS_SSL_REQUIRE_SAFE_NEGOTIATION, NSS_SSL_ENABLE_RENEGOTIATION,
and NSS_SSL_CBC_RANDOM_IV, all of which have security implications. Some were
put in for some Thunderbird problem involving Microsoft mail servers, but the
common library may enable them in Firefox as well. That whole section of code
should be present only debug builds, if at all.

It's funny how backdoors like this keep creeping into mainstream software,
isn't it. Look at the code histories and see who put in those changes.

~~~
scintill76
This does seem, at the least, irresponsible of the browser vendors. I'll be
especially angry if Chrome doesn't have very prominent warnings, considering
they harass some developers and power users with a warning about an "insecure"
configuration Google basically forced them to use.[0] By analogy, I expect
nothing less than a blinking red warning covering the entire browser window
whenever keys are being logged because of an environment variable.

I also don't think readers should be encouraged so readily to put this into
the persistent global environment.

[0]
[https://code.google.com/p/chromium/issues/detail?id=337734](https://code.google.com/p/chromium/issues/detail?id=337734)

~~~
reubenmorais
Chrome uses NSS, so the GP applies exactly to it:
[https://code.google.com/p/chromium/codesearch#chromium/src/n...](https://code.google.com/p/chromium/codesearch#chromium/src/net/third_party/nss/ssl/sslsock.c&q=SSLKEYLOGFILE&sq=package:chromium&type=cs&l=2984)

------
nailer
Small super-pedantic note: the correct file 'so that it is set every time you
log in' on both OS X and Linux would be .bash_profile.

\- .bashrc is run every time the shell is started (eg, subshells, su without
-l or -)

\- .bash_profile is run only when a 'log in' shell is started, eg, a tty, su
-l, su-, new tab, etc.

------
ecesena
Very interesting combo!

Another technique that often, sadly, works is the old school man-in-the-
middle.

I was recently looking at the api of an app on my phone, using ettercap to arp
poison my phone and capture traffic on my laptop. Found the api call was over
https (fwd secrecy and all looking good), I tried ssl-mitm with a fake cert...
no errors in the app, clear text on my laptop. Happy and sad at the same time.
:/

~~~
mdaniel
What an amazing and scary tool (maybe those always go together). I now have a
_much_ deeper appreciation for why folks are afraid of Starbucks WiFi.

~~~
notfoss
Any decent browser will display a certificate error for a Mitm attack. But
yes, if you are using other programs/apps over an untrusted network, you can
never be sure.

------
lucb1e
I can't help but wonder how many people are going to apply this handy trick to
people's unlocked Windows sessions...

~~~
bigiain
I'm looking forward with interest to see how long it takes for a piece of
malware to start reconfiguring exploited machine's browsers and exfiltrating
session keys.

(Or, to the news that the NSA/GHCQ/ASIO/et al. have been actively doing this
for years already...)

~~~
skolor
Have we seen malware ripping keys out of memory? It seems a stretch to think
that making this slightly easier to do will result in it being more
widespread. What reason does malware have to do this that isn't better served
by DNS Hijacking + installing a root cert?

~~~
bigiain
This gets an attacker session keys for TLS sessions with forward privacy -
which'd be kinda handy if you were a (the?) "global passive adversary" who's
already syphoning off _all_ the traffic in and out of the major cables and
datacenters.

------
theatraine
This is handy, but you can very easily do this automatically with fiddler. It
automatically swaps out all of the certs though.

~~~
gear54rus
Do you mean using Fiddler (great program, definitely a musthave) in place of
Wireshark?

In that case you can add its key to a trusted authorities in Firefox and then
it swaps nothing, everything seems to be signed properly... Unless I
misunderstood your comment.

~~~
theatraine
I meant that Fiddler switches the original certificates with certificates that
it generates. It's not a big deal if you trust them (on Windows Chrome and IE
work automatically since it adds them to the trusted root store) and for
Firefox you just have to trust the Fiddler issued certificate. However, if you
inspect the certificate of an HTTPS site when Fiddler is running you see the
CA is "DO_NOT_TRUST_FiddlerRoot".

~~~
platz
I believe mitmproxy also sniffs HTTPS, but I think it uses a different method
by dynamically generating a cert based on the true one
[http://mitmproxy.org/doc/howmitmproxy.html](http://mitmproxy.org/doc/howmitmproxy.html)
(bottom)

------
Torgo
I just dealt with this a couple months ago, and had to explain to my boss why
I reverted from best-practice SSL settings in the course of trying to solve a
tricky problem. Another issue I ran into was, the current packaged version of
Wireshark in Ubuntu had some bugs in it that also prevented me from decrypting
traffic (it didn't tell me this, it just didn't work and I had to track down
the problem myself.) I had to compile the latest from their website to finally
get everything working.

------
Legogris
If you're going to debug your own services (where you can own the certificate
key) you can also do this easily by tcpdump and then importing the encrypted
dump and decrypting it inside Wireshark:
[http://support.citrix.com/article/CTX116557](http://support.citrix.com/article/CTX116557)

I had to verify how two services (not web browsers) were communicating the
other day and this was the easiest solution for me.

~~~
andor
Take a look at the first paragraph. With Forward Security, having the private
key is not enough, you need the session keys.

