Handshakes, versions, and resumption
A handshake costs at least one round trip, and by track 2 you know what a round trip costs. Almost every difference between TLS 1.2 and TLS 1.3 is an attempt to remove one.
Here is the older version, for comparison:
Why 1.2 needed two round trips
The client could not send a key share in its first message, because it did not yet know which group the server would choose. So: hello, wait for the server to name a group, send a share, wait again. Two round trips before any application data.
TLS 1.3 makes the client guess. It sends a key share for the group it thinks the server will pick, along with its hello, and is right almost every time. When it is wrong the server asks it to retry — costing exactly the round trip 1.2 always paid.
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| Round trips, cold | 2 | 1 |
| Certificate on the wire | In the clear | Encrypted |
| Encryption begins | At ChangeCipherSpec | Right after ServerHello |
| Forward secrecy | Optional | Mandatory |
| Cipher suite names | Four components | Two |
The plaintext certificate is more than an aesthetic problem: under TLS 1.2 anyone watching learned the identity of the site from the connection itself, with no need for SNI.
Resumption, and the temptation of zero
If the client has spoken to this server before, it holds a ticket. Presenting it replaces the whole identity exchange — no certificate, no signature, no verification — because holding the pre-shared key is itself the proof.
And once there is a key before the handshake begins, the client can send its request immediately, in the very first flight. That is 0-RTT.
Key takeaways
- A handshake costs round trips, and the version history of TLS is largely a record of removing them.
- TLS 1.2 needed two because the client could not send a key share until the server named a group; 1.3 guesses and is nearly always right.
- TLS 1.3 encrypts the certificate. Under 1.2 it crossed the wire in the clear, revealing the site to any observer.
- Resumption replaces the certificate exchange with a ticket: holding the pre-shared key is itself the proof of identity.
- 0-RTT data is replayable by construction and is not forward secret, so only idempotent requests belong in it.