1. C & S exchange messages to agree on versions, ciphersuites, and nonces.
2. S->C certificate, which includes an RSA public key.
3. C verifies certificate against its local cache of CA roots.
4. C->S random secret encrypted under the RSA key (the "pre-master secret").
5. C & S derive (the same) set of MAC keys, crypto keys, and crypto parameters.
6. C & S verify every message of the handshake with the MAC keys.
Other useful things to know:
* SSL/TLS operates over a "record layer" of TLV-style messages. The TLS record layer itself supports fragmentation, which is a little crazy.
* The server can ask the client to send a certificate too; this is common on backend connections and unfortunately not common with browsers, because the UI is terrible.
* Less commonly, C & S can opt for a "DHE" (ephemeral Diffie-Hellman) key exchange, in which the RSA key from the certificate is used to sign a DH key exchange (DH allows both sides to use random public keys instead of long-term fixed keys, but suffers from exposure to MITM attacks --- the RSA key from the cert "breaks the tie" in a MITM situation, making the exchange secure). This has the advantage of ensuring that even if an attacker has been recording all your traffic for years, she can't compromise a server's private key and then decrypt older connections. This is called "forward secrecy".
* The two common cipher suites used on most connections are AES in CBC mode and RC4. AES-CBC chunks plaintext into 16 byte blocks, padding the last block if there are insufficient bytes to fill it. Until TLS 1.1, TLS ran CBC in a continuous stream over the whole connection, using the last block of the most recent message as the IV for the next, which gave rise to the BEAST flaw. RC4 is a stream cipher that encrypts byte-at-a-time --- but nobody trusts RC4 much.
* TLS 1.2 (IIRC) introduces AES-CTR, which runs AES as a stream cipher.
Hmmm. I'm sure browser certs is a well-worn topic, so maybe you could just point me to a proposal/discussion about it, but I don't really see the benefit client keys have over per-user symmetric tokens if each app is its own CA. Symmetric tokens can also be distributed/stored without special browser support.
The cryptosystem required to do per-app certificates is already resident in every mainstream browser; we are literally a UI/UX fix away from having that working.
Meanwhile, to a first approximation, zero people have tokens.
Web servers would have to be retrofitted to sign, distribute, and authenticate client certificates, so there is O(apps) work to be done. For symmetric tokens, each app would just have to store the token in the user DB, and then tell the client to hold it in local storage, which is probably less work for the server admin, and also doesn't require browser support.
I've always wondered if / what is stopping someone from eves dropping or duping the initial handshakes before the communications are encrypted. If you get the cipher and understand the schema used you should be able to decode the otherwise secure traffic.
in step 4 above the client sends data to the server that is encrypted with the server's public key. you don't have the server's private key, so you cannot decrypt that data. but the server can. so you cannot duplicate things, even if you are watching.
I agree with the commenters on SE that say "Thomas Pornin will have the best answer". While I absolutely understand the utility of SE's competition to produce the best message, I find it destroys any interest I have in contributing to the site.
1. C & S exchange messages to agree on versions, ciphersuites, and nonces.
2. S->C certificate, which includes an RSA public key.
3. C verifies certificate against its local cache of CA roots.
4. C->S random secret encrypted under the RSA key (the "pre-master secret").
5. C & S derive (the same) set of MAC keys, crypto keys, and crypto parameters.
6. C & S verify every message of the handshake with the MAC keys.
Other useful things to know:
* SSL/TLS operates over a "record layer" of TLV-style messages. The TLS record layer itself supports fragmentation, which is a little crazy.
* The server can ask the client to send a certificate too; this is common on backend connections and unfortunately not common with browsers, because the UI is terrible.
* Less commonly, C & S can opt for a "DHE" (ephemeral Diffie-Hellman) key exchange, in which the RSA key from the certificate is used to sign a DH key exchange (DH allows both sides to use random public keys instead of long-term fixed keys, but suffers from exposure to MITM attacks --- the RSA key from the cert "breaks the tie" in a MITM situation, making the exchange secure). This has the advantage of ensuring that even if an attacker has been recording all your traffic for years, she can't compromise a server's private key and then decrypt older connections. This is called "forward secrecy".
* The two common cipher suites used on most connections are AES in CBC mode and RC4. AES-CBC chunks plaintext into 16 byte blocks, padding the last block if there are insufficient bytes to fill it. Until TLS 1.1, TLS ran CBC in a continuous stream over the whole connection, using the last block of the most recent message as the IV for the next, which gave rise to the BEAST flaw. RC4 is a stream cipher that encrypts byte-at-a-time --- but nobody trusts RC4 much.
* TLS 1.2 (IIRC) introduces AES-CTR, which runs AES as a stream cipher.