The TLS 1.3 handshake

Before any data flows over a TLS connection, both ends need a shared secret key that nobody watching the network can learn. The handshake is how they agree on that key and how the server proves who it is. TLS 1.3 does both in one round trip, down from two in TLS 1.2.

The big idea: ephemeral keys

The core trick is ECDHE (Elliptic Curve Diffie-Hellman, Ephemeral). Each side makes a new key pair for this one connection. It sends the public half, and combines its own private half with the other side's public half. Both arrive at the same shared secret. Someone who sees both public halves still cannot compute it.

"Ephemeral" means the key pair is discarded when the connection ends. That gives forward secrecy. If the server's long-term private key is stolen next year, traffic recorded today still cannot be decrypted, because the session keys no longer exist anywhere.

Walking through the messages

1. ClientHello (plaintext). The client lists its supported versions and cipher suites, the name it wants (SNI), the protocols it speaks (ALPN, such as h2), and a key share, its public key.
2. ServerHello (plaintext). The server picks a cipher suite and sends its own key share. Both ends now compute the shared secret. Everything after this is encrypted.
3. Certificate. The server sends its certificate chain. See certificates and chains.
4. CertificateVerify. The server signs the handshake so far with its certificate's private key. This proves it holds that key.
5. Finished. Both sides confirm the handshake with a message authentication code over the transcript.
6. The client checks the certificate and the signature, then sends its own Finished. It can send the HTTP request in the same flight.

Counting round trips

A new HTTPS connection over TCP needs one round trip for TCP and one for TLS before the request can leave. At 150 ms round-trip time:

TLS 1.3:  TCP 1 RTT + TLS 1 RTT = 2 × 150 ms = 300 ms before the request
TLS 1.2:  TCP 1 RTT + TLS 2 RTT = 3 × 150 ms = 450 ms before the request

Connection reuse matters more than either number. A client that makes 1,000 requests over one keep-alive connection pays the handshake once.

Resumption and 0-RTT

At the end of a handshake, the server can send a session ticket, an encrypted blob the client presents next time. The server then skips the certificate exchange and uses a key derived from the first session. Resumption still takes one round trip, but it skips the signature work.

TLS 1.3 also allows 0-RTT. On resumption, the client sends its first request in the same flight as ClientHello. That request needs no handshake round trip.

Operating notes

• Load balancers. Session ticket keys must be shared across every load balancer and rotated together. Otherwise resumption fails whenever a client lands on a different node.
• Revocation. OCSP asked the CA about each certificate on every connection, which added latency and told the CA which sites were visited. OCSP stapling lets the server send a signed status instead. Many systems now rely on short lifetimes instead, covered in certificate expiry and renewal.

Common mistakes

• Counting only the TLS round trip. TCP adds one more before TLS starts.
• Sending unsafe requests as 0-RTT data. Only repeatable requests are safe to replay.
• Forgetting to share session ticket keys. Resumption then fails on random load balancers.

Check yourself

1. Why does forward secrecy protect traffic recorded today if the server key is stolen next year? The session keys came from ephemeral key pairs that were discarded after the connection. Without them, the recorded traffic cannot be decrypted.
2. Why is 0-RTT limited to safe requests? Early data can be captured and replayed, so a non-repeatable action like a payment could run twice.

Key takeaways

• TLS 1.3 agrees on keys in one round trip using ephemeral ECDHE key pairs.
• Forward secrecy comes from discarding the session keys after use.
• A new connection costs TCP plus TLS round trips before the first request. Reuse connections.
• 0-RTT removes the wait but allows replay, so only repeatable requests belong in early data.

Further learning

Mike Pound's Computerphile episode explains why the key exchange and the signature are separate steps, at a whiteboard pace.

The Illustrated TLS 1.3 ConnectionEvery byte of a TLS connection explained and reproducedtls13.xargs.org