12 Aug: Adventures in TLS

TLS operates on top of TCP to provide a secure connection. Often, although doesn't have to be, used with HTTP (HTTPS is HTTP+TLS). Here's a brief simplified overview of how it works:

1. The client sends the server some details on what standards to use for the connection: version of SSL/TLS, cipher suites, compression methods
2. The server selects the best version and cipher suite that's mutually supported
3. The server sends the client its SSL certificate. This is typically signed by a trusted 3rd party to prove the server is who the client thinks it is.
4. (Start of DH key establishment) Now a shared key is exchanged which is going to be the base for the symmetric encryption key. This is encrypted with the SSL certifcate as the public key so only the server can decrypt it with its private key.
5. The client and server both generate their own key, and combine with the shared key. Its important to note that it is computationally difficult to "uncombine". They exchange the combined key to the other party. Using mathematical properties, each can then derive the same key to be used for the connection without ever actually trasnfering the key over the wire (end of DH key establishment)
6. The client sends the server an encrypted message (MAC) and the server checks is can decrypt it.

From this point, the two hosts can talk securely to each other. The server's identify has been verified (the SSL certifcate) and the communication is now secret (encrypted with the DH generated private key).

The DH key exchange provides forward secrecy. Without it, if you're relying only on the random number from the client encrypted with the public key (certificate), and decrypted using the private key of the server, then if the private key is compromised, the attacker can go back and decrypt any previous message. Forward secrecy means even if you break the encryption key for one connection, its useless for any other connection.