3 ms·
Maybe a nitpick, but I think this section could be clearer: "Except HTTPS traffic won't show up on Malory's screen: things encrypted with a website's public ke
by stygiansonic 11y ago
Maybe a nitpick, but I think this section could be clearer:
"Except HTTPS traffic won't show up on Malory's screen: things encrypted with a website's public key can only be decrypted with the website's private key. Because the website's private key is (hopefully) only available to the website, Malory can't decrypt the traffic."
I know it's just an overview, but this explanation seems a bit confusing. I mean, it's true that the trust is anchored on the private key but that's only one part of it.
My (simple) understanding of TLS is that basically, the public/private keys are used to secure the shared secrets used to derive the symmetric session keys OR to authenticate something like a DH key exchange that's used to derive the session keys. In the first case, the client would generated a shared secret, encrypt with the public key, and then send to the server. In the second case, the authenticated DH key exchange allows both client/server to arrive at the shared secrets.
In either case, it's these symmetric session keys which are used to encrypt/decrypt the traffic.
My understanding is that even if you capture the encrypted traffic and then later on, you obtain the private key, you wouldn't be able to decrypt the traffic if the parties used something like a DH key exchange. (This would be (perfect) forward secrecy?) Of course if you have the private key and no one knows yet, then you could impersonate the server and MiTM future connections, I think.
Someone with better knowledge could explain this better.
- bmm6o 11y agoYou're comments are correct, but I don't think replacing the 1 brief paragraph in TFA with your 3 would improve the article.