The TLS handshake

The handshake is usually described as the part where encryption gets turned on, which makes it sound like a formality before the real work. It is closer to the opposite: the encryption is the easy part, and the handshake exists because encrypting a channel to an unverified party protects the conversation from everyone except the one person you should be worried about.

What is actually being agreed#

RFC 8446 sets out what the handshake is for, and the list is longer than “set up encryption”. The peers negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material. Four jobs, and only the last produces the keys — the other three decide whether those keys mean anything.

The specification structures the exchange in three stages. Key exchange establishes shared keying material and selects the cryptographic parameters, and everything after that point is encrypted. Server parameters settles the remaining handshake configuration, such as whether the client will be asked to authenticate and which application-layer protocol will run. Authentication then authenticates the server — and optionally the client — and provides key confirmation and handshake integrity, concluding with a Finished message that binds the endpoint’s identity to the keys just exchanged.

That binding is the sentence to hold on to. It is not enough to have agreed keys and separately seen a certificate; the protocol has to tie the identity to these keys, or an attacker could present someone else’s credentials over a channel they control. All of this runs above an established TCP connection, which is why TLS sits awkwardly in any layered model — it is doing work no single layer was defined to hold.

The order is the security#

Encrypting first and authenticating afterwards looks backwards until you notice what each step protects. The key exchange gives both ends a shared secret without ever sending it, so an observer who recorded every byte still cannot derive it. That makes the channel private immediately — from passive observers — and lets the rest of the handshake, including the certificate, be encrypted rather than sent in the clear.

Privacy from an observer is not the same as talking to the right party, though, and that is what authentication settles. An attacker who can intercept and modify traffic could complete a key exchange with you perfectly well; what they cannot do is produce a valid signature for a name they do not hold the private key for. The handshake fails at that step rather than at the encryption step, which is why certificate errors are the ones browsers refuse to let users click past casually.

TLS 1.3’s removals follow the same logic. Static RSA and Diffie-Hellman cipher suites are gone, along with compression and DSA, and the older resumption mechanisms are replaced by a single pre-shared key exchange. Each removal deletes a way for two conforming implementations to negotiate their way into something weak — the recurring lesson that a protocol’s guarantees are exactly the ones it refuses to make optional.

What the fastest mode gives up#

A full handshake costs a round trip before any application data moves, and on a high-latency connection that is the visible cost of the whole exchange. TLS 1.3 offers a way around it for parties that have spoken before: using a pre-shared key from a previous session, a client can send data on its first flight. That is 0-RTT, and it is genuinely fast.

The specification is careful about what it costs, and the phrasing is worth quoting exactly rather than summarising. Data sent this way is not forward secret, and it carries no guarantees of non-replay between connections. The second clause is the operational one: an attacker who records a 0-RTT request can send it again later, and the server has no protocol-level way to tell the copy from the original.

Which turns a transport decision into an application one. A request that reads a page can be replayed harmlessly. A request that transfers money, cancels an order or increments a counter cannot, and the protocol will not stop it — so anything sent in 0-RTT has to be safe to receive twice. That is precisely the property an endpoint built to survive a duplicate request already has, arriving here from the transport rather than from a retry.