Daniel Lorch wrote:
Are you sure? Isn't that exactly the point of asymmetric cryptography? The way I see it, TLS and SSL work like this (analogous to PGP):
You're almost right.
- The client connects to the server and obtains the server's public key. The public key is a mathematical recipe to encode (but not decode) a message for a specific recipient.
ACK.
- Using this public key, the client encodes the message (cleartext -> ciphertext). Now the interesting part is, that the client isn't able to decode this cipher text he just encoded, because he doesn't have the private key (that's why it is also necessary to always encrypt PGP messages to yourself, otherwise you won't be able to read them later on in your "sent" box).
SMTP/TLS does not encrypt individual messages - as it's name implies, it works on the *transport* layer. And there, the public key exchange is used to agree on a symmetric session key.
Btw., neither server nor client public keys would technically be required; anonymous DH would work as well (although it would not make much sense...).
I could now connect to the mail server, obtain the public key and generate as many cleartext/ciphertext pairs as I want and I still would not be able to guess the private key from that information.
Of course, known-plaintext, replay and similar attacks on TLS and SSL are theoretically possible. However, I have not heard of practically possible or generally successful attacks.
-- Matthias