5 ms·

Decrypting TLS Browser Traffic with Wireshark

theatraine 12y ago
This is handy, but you can very easily do this automatically with fiddler. It automatically swaps out all of the certs though.
- deleted 12y ago
  [deleted]
- gear54rus 12y ago
  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 12y ago
    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 12y ago
      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)
  - throwaway8384 12y ago
    No, Fiddler is an active ManInTheMiddle attack. With HTTPS interception it always substitutes the certificate (which is the public key). The substituted public key allows the proxy to negotiate a TLS session between the browser and the proxy, impersonating the real server. You avoid a certificate error if you install the signing CA certificate in the browser; but you still tamper with the traffic. There are scenarios where mitm doesn't work; for example Client Authenticated TLS. Things like certificate pinning, where the browser expects a specific public key, also break intetception.
  - charlesnw 12y ago
    Spaces. Use them. I read "musthave" as "mutshave" :)
    - gear54rus 12y ago
      Come to think of it I'm never sure how to write those 2-part words being a non-native speaker. I just go with what seems right :)
- teh_klev 12y ago
  Sure, but if you want to see the whole stack (below HTTP/S) you can't do that with fiddler.
- mobiplayer 12y ago
  I find httpWatch with Firefox and IE much better than Fiddler for HTTP debugging purposes. However it is not free.
lucb1e 12y ago
I can't help but wonder how many people are going to apply this handy trick to people's unlocked Windows sessions...
- bigiain 12y ago
  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 12y ago
    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?
    - lstamour 12y ago
      This might get around pesky certificate pinning ;-)
    - bigiain 12y ago
      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.
  - nitrogen 12y ago
    I have seen malware that repeatedly adds a compromised root certificate to a machine's trusted authorities.
Torgo 12y ago
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.
ecesena 12y ago
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 12y ago
  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 12y ago
    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.
  - ecesena 12y ago
    It's not actually about the WiFi, secure or not. I was in a WPA2 WiFi. I attacked my phone (at a higher network level), so unless there's an active IDS in place, you can't do much about it. The issue is not the network, but the way the app continued over an insecure connection.
- mobiplayer 12y ago
  Wait a second... Was the fake cert trusted by your phone? If affirmative, did you manually add the root cert from your fake CA or at least accepted that cert as trusted? If you didn't explicitly trust that cert and the application didn't complain we're in front of another completely wrong use of SSL.
  - ecesena 12y ago
    No, not trusted. That's why I was sad. The app failed to verify the certificate chain and silently continued over the (in)secure connection.
nailer 12y ago
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.
Animats 12y ago
That article seems to be a rewrite of this 2012 article: http://www.root9.net/2012/11/ssl-decryption-with-wireshark-private.html http://www.root9.net/2012/11/ssl-decryption-with-wireshark-p... 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.crypto/bu3b9x12c1Q https://groups.google.com/forum/#!topic/mozilla.dev.tech.cry...) 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/ssl/sslsock.c#l2840 https://hg.mozilla.org/projects/nss/file/65605e800fd1/lib/ss... 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 12y ago
  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 12y ago
    Chrome uses NSS, so the GP applies exactly to it: 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 https://code.google.com/p/chromium/codesearch#chromium/src/n...
Legogris 12y ago
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 12y ago
  Take a look at the first paragraph. With Forward Security, having the private key is not enough, you need the session keys.

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

deleted 12y ago
[deleted]
gear54rus 12y ago
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 12y ago
  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 12y ago
    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)
- throwaway8384 12y ago
  No, Fiddler is an active ManInTheMiddle attack. With HTTPS interception it always substitutes the certificate (which is the public key). The substituted public key allows the proxy to negotiate a TLS session between the browser and the proxy, impersonating the real server. You avoid a certificate error if you install the signing CA certificate in the browser; but you still tamper with the traffic. There are scenarios where mitm doesn't work; for example Client Authenticated TLS. Things like certificate pinning, where the browser expects a specific public key, also break intetception.
- charlesnw 12y ago
  Spaces. Use them. I read "musthave" as "mutshave" :)
  - gear54rus 12y ago
    Come to think of it I'm never sure how to write those 2-part words being a non-native speaker. I just go with what seems right :)
teh_klev 12y ago
Sure, but if you want to see the whole stack (below HTTP/S) you can't do that with fiddler.
mobiplayer 12y ago
I find httpWatch with Firefox and IE much better than Fiddler for HTTP debugging purposes. However it is not free.

lucb1e 12y ago

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

bigiain 12y ago
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 12y ago
  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?
  - lstamour 12y ago
    This might get around pesky certificate pinning ;-)
  - bigiain 12y ago
    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.
- nitrogen 12y ago
  I have seen malware that repeatedly adds a compromised root certificate to a machine's trusted authorities.

Torgo 12y ago

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.

ecesena 12y ago

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 12y ago
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 12y ago
  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.
- ecesena 12y ago
  It's not actually about the WiFi, secure or not. I was in a WPA2 WiFi. I attacked my phone (at a higher network level), so unless there's an active IDS in place, you can't do much about it. The issue is not the network, but the way the app continued over an insecure connection.
mobiplayer 12y ago
Wait a second... Was the fake cert trusted by your phone? If affirmative, did you manually add the root cert from your fake CA or at least accepted that cert as trusted? If you didn't explicitly trust that cert and the application didn't complain we're in front of another completely wrong use of SSL.
- ecesena 12y ago
  No, not trusted. That's why I was sad. The app failed to verify the certificate chain and silently continued over the (in)secure connection.

nailer 12y ago

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.

Animats 12y ago

That article seems to be a rewrite of this 2012 article: http://www.root9.net/2012/11/ssl-decryption-with-wireshark-private.html http://www.root9.net/2012/11/ssl-decryption-with-wireshark-p... 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.crypto/bu3b9x12c1Q https://groups.google.com/forum/#!topic/mozilla.dev.tech.cry...) 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/ssl/sslsock.c#l2840 https://hg.mozilla.org/projects/nss/file/65605e800fd1/lib/ss... 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 12y ago
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 12y ago
  Chrome uses NSS, so the GP applies exactly to it: 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 https://code.google.com/p/chromium/codesearch#chromium/src/n...

Legogris 12y ago

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 12y ago
Take a look at the first paragraph. With Forward Security, having the private key is not enough, you need the session keys.