Hacker News Reader

Comment by arkadiyt | Hacker News Reader

"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

View on HN

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/

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.

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

Reply on news.ycombinator.com