Some sites use certificate pinning, and once the browser accesses the real site it will remember that site shouldn't be using a dodgy MITM cert (even if it trusts it), and will refuse to connect. Now yes, if the browser trusts your private CA and your mitm proxy generates a valid (according to that private CA), it will still be able to decrypt, however that only works for some sites. is a good post on perfect forward secrecy. With DH, it uses magic* to generate a new key on connection, so even if you have the private key you can't decrypt the This was used for a secure mail provider some years ago - the courts forced them to give up their private key, and the TLA agency could then go back and decrypt all the traffic they'd captured from $BADGUY.Īlternatively, if you could get the browser's key, you could decrypt the encrypted traffic from a pcap file in Wireshark for the session. With non Diffie Hellman connections (which were possible in TLS1.2 and below but you say aren't for TLS1.3, I haven't checked), you can store all the encrypted traffic, and once you get the private key, you can decrypt it So which one is it guys?Īlso, just so I'm clear as well, TLS1.3 works via both ends creating 2 values and sharing the 'shared key' value and keeping the private key to themselves, when each receive eachothers shared key, then using their own private keys they can come to the same shared master key and use that to encrypt and decrypt traffic and use it to pass through the symmetrical AES key used for actual encryption? The first paragraph makes sense to me but then he contradicts himself it comes across like when he says MITM decryption is still possible, well that's what an ISP/SSL next gen firewall does for the job and in the first he's saying it won't be able to do it because of the way TLS1.3 works now. As long as your internal clients trust the device’s CA certificate then it will still be able to spoof the certificates and sit in the middle just as it does for TLS 1.2 today.' Inline “Man in the middle” decryption (as implemented on many firewalls and proxies) however will still be entirely possible. some sort of agent on your endpoints sends it securely to the appliance in question). Not something that really exists at the moment, but potentially something that could end up coming out the back of this in the end (e.g. They only way they would be able to decrypt data would be for one end of the conversation to provide a copy of the actual session key somehow. cannot passively decrypt traffic even with a copy of the private key. The fact all key-exchanges will use Diffie Hellman means that devices such as IPS etc.

'Firstly, passive out-of-band decryption is out. It comes across as a really useful informative blog on it and I understood 99% of it, up until the part where he mentions. Are there many sites anymore that use TLS1.2, if not then is there much point in SSL decryption anymore?

Hi, I'm in the middle of going through the process of implementing SSL decryption on Firepower and going through what I should/need to decrypt but have also learned that if a website is using TLS1.3 then I won't be able to decrypt the traffic regardless.

Wireshark decrypt tls 1.3