Decrypting TLS Browser Traffic with Wireshark (2015) | Hacker News Reader

Decrypting TLS Browser Traffic with Wireshark (2015)

jimshaver.net

159 pointsrosstex26 comments

Sniffing encrypted traffic can also be done with Fiddler (admin account required) and NetRipper (no admin requirement): https://tinyapps.org/blog/windows/201508150700_sniffing_encr...

On a related note, to extract webmail passwords and more from memory, check out mimikittenz: https://github.com/putterpanda/mimikittenz . Basic usage: https://tinyapps.org/blog/windows/201607080700_extract_passw...

CHARLES also works really well and in my opinion has a better UI than Fiddler.

It can also be used to capture encrypted traffic on another device.

Worth pointing out that Charles isn't free [0], unlike Fiddler. It used to be that on Mac/Linux you didn't have many choices but there is now a Beta of Fiddler for Mac and an Alpha for Linux (using Mono) [1].

[0]: https://www.charlesproxy.com

[1]: https://www.telerik.com/download/fiddler

Thanks for the pointer to NetRipper; tinyapps.org is the best!

Fiddler MITM's creating a self-signed cert for each domain, which fails on apps that do cert pinning. I didn't get far enough to try but it also sounded like it didn't support smart cards for client certs in this mode either, asking for the private key in a file.

Just turning on the 'open dev tools for new windows' setting in Chrome is often enough to get what I need easily.

"tinyapps.org is the best"

Thanks so much for the kind words, j_s. I'm afraid (or perhaps the word I'm looking for is "glad" ;-) that the Internet has passed tinyapps.org on by. After its fleeting 15 seconds of fame back in 2001 (thanks to a Slashdotting and tiny blurb in Wired), the site has mainly served as an irregular tech blog lo these many years.

Sorry that Fiddler did not prove efficacious. Thank you for the Chrome tip!

Fiddler is great. Hadn't heard of NetRipper. Will take a look, thanks.

Also worth considering is Microsoft Message Analyzer, which used to be Network Monitor (NetMon). https://blogs.technet.microsoft.com/MessageAnalyzer/

Edit: I should add that this isn't an endorsement, just another option. I only included MMA as a side-note in my recent book. I focussed on Wireshark and Fiddler to keep things simple.

Go 1.8 (in development) will have support for logging TLS secrets in the format required for Wireshark https://tip.golang.org/pkg/crypto/tls/#example_Config_keyLog.... It needs to be enabled on the tls.Config though so needs a special build.

Full disclosure: it's my contribution.

"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"

This seems to imply it's impossible to decrypt the traffic due to the key exchange algorithm used, but isn't it actually an implementation issue of Wireshark? Yes, it can't decrypt old traffic (i.e. a pcap file) due to forward secrecy, but it should be possible to decrypt any on-the-fly traffic after knowing the private key by actively MITM-ing the connection

But Wireshark is not a MITM tool, it's a packet sniffer. You'd need to use ettercap or similar also.

No, with a packet capture and the private keys from both sides, you would still not be able to identify the master secret negotiated out of the dh key exchange.

However, both sides obviously know the master secret, so if you can extract it from one of the clients then you can use that in wireshark to decrypt the application data packets. In wirshark preferences, this is called the pre-master-secret log filename.

No. Even if wireshark listened to the entire key-exchange, it would not be able to reconstruct the key, that's the whole point of a key exchange. The client generates some secret part, the server generates some secret part, they both do math to their secret parts to get some stuff they can exchange safely. After they've exchanged the stuff, both can combine the public stuff with their own secret parts to generate the same key. If you just saw the public stuff exchanged in between, but didn't have access to one of the secret parts, you couldn't (feasibly) reconstruct the key.

As for acting as a MITM, Wireshark would have the same problem as anybody else in between the server and client: it doesn't have a valid certificate. Chrome would throw up a big scary warning and make it almost impossible to use the site.

As others here are pointing out, with passive monitoring (i.e. Wireshark) you can't decrypt Perfect Forward Secrecy (PFS) traffic even if the private keys are known / later discovered. This is by design and is the great thing about ephemeral Diffie-Hellman key exchange. The private keys would only allow you to impersonate the server in an active attack, not decrypt a new direct connection.

The key is never transmitted (even in encrypted form), unlike with RSA. A good way of thinking about this is with a colour mixing analogy. I had a go at explaining this (with a Lego stormtrooper) here: https://unop.uk/understanding-encryption-and-key-exchange/

Security considerations:

I'm a little wary of exporting SSLKEYLOGFILE into my systemwide environment. Everything can see it's set. Nothing stopping malware from grepping your disk for the string, sure, but seeing it in the environment is a practical guarantee the file it points to will successfully decrypt all HTTPS traffic. This feels a bit scary to me, since it's set-and-forget. (Or am I being too paranoid?)

Linux and macOS are easy to fix, just set the var in some obscure way you choose.

Windows is unfortunately less easy to fix; setting env vars per-process generally requires cmd.exe to flash on the screen, it seems :/

I wonder how long this will remain compiled into the official versions of Firefox and Chrome after it starts being used by malware.

Also if anyone has used this to document everything Chrome sends back to the mother ship with its pinned certs.

And finally if it will be possible to implement something similar for IE and the rest of Windows (spyware/analytics) with Alex Ionescou's soon-to-be-released kernel driver interception framework.

If malware can set arbitrary environment variables, it can also typically analyze and/or modify browser memory.

How so? It would seem like a minor configuration change would be unrelated to accessing a process's memory. But I'm not a security guy.

I was looking at an anti-malware endpoint security product today. I have to use it, but I'm seriously dubious as to how useful it's going to be. Saw this article.

Hey, hey, what do you know. First try with wireshark and I'm reading the ssl from the protected computer.

Not limited to http.

http://databaseblog.myname.nl/2014/07/decoding-encrypted-mys...

I've been trying to implement a youtube-dl plugin that can download Echo360 videos (a proprietary, flash-based video streaming service that many universities use to host their l lecture recordings). This has been invaluable in order to figure out the protocol that the player uses (though it appears that their flash player doesn't use any crypto at all, which is a relief).

sslkeylog is both an LD_PRELOAD library and python gdb script for openssl servers (e.g. haproxy): https://git.lekensteyn.nl/peter/wireshark-notes/tree/src

Does this mean...... anyone can MITM traffic over TLS that's encrypted?

No, you need to get the keys from your browser: "It turns out that Firefox and Chrome both support logging the symmetric session key used to encrypt TLS traffic to a file."

No. You still need the session key stored by the clients browser. (In this case Firefox or Chrome)

> Well my friends I’m here to tell you that there is an easier way! It turns out that Firefox and 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.

No. The article is instructions that set up Chrome to share the encryption/decryption key with Wireshark. Without that key, the traffic can not be decrypted.

The key only exists in Chrome and on the receiving webserver (and, if you follow the instructions, that file on disk, and then Wireshark). Once the key is discarded by all who hold it, the ability to decrypt the TLS session is lost.

This provides a way to get access to the connections that Chrome or Firefox setup, since normally those keys are stored internally by the browsers.

Well, anyone who has access to the environment of the browser.

Reply on news.ycombinator.com