The TLS 1.3 handshake — a channel in one round trip
From ClientHello to Finished: how key agreement, certificates, signatures, and tamper detection assemble into one round trip — plus SNI and 1-RTT.
The parts are all here — now assemble them
The previous chapters handed us every part we need: key agreement (Chapter 3) builds a shared secret over a wiretapped path, certificates and signatures (Chapters 2 and 4) confirm the peer is genuine, and symmetric encryption with tamper detection (Chapter 2) protects the traffic. The TLS 1.3 handshake assembles all of it into a single round trip.
Rather than memorizing "what comes next," this chapter checks, for each message: which chapter's tool is this, and which question does it answer?
The TLS 1.3 handshake at a glance. Key agreement completes at ServerHello; everything after it (the shaded region) is already encrypted.
Outbound: ClientHello — introduction and public value in one
The client's first message, ClientHello, carries:
- Supported TLS versions and cipher candidates — "here is what I can speak"
- key_share = the DH (ECDHE) public value — Chapter 3's "A," included up front
- SNI (Server Name Indication) — the host name being requested, so a server hosting many domains on one IP can choose which certificate to present
Through TLS 1.2, "agree on parameters" and "exchange keys" were separate round trips — two in total. TLS 1.3 compresses this to one by shipping the public value in the first message. Note that ClientHello predates key sharing, so it cannot be encrypted — the SNI host name is visible on the path. That is the mechanism behind Chapter 1's "the domain is visible even under HTTPS."
Inbound: ServerHello through Finished — everything at once
The server answers with its chosen parameters and its own public value (key_share) in ServerHello. At that moment, both sides can compute the shared secret. TLS 1.3 derives keys immediately, encrypts everything that follows, and packs it into the same flight:
The client verifies, returns its own Finished, and can send application data (the HTTP request) in the same flight. One round trip from ClientHello — the "1-RTT handshake."
Practice 5-1 — Inside the single round trip
Answer while keeping track of which chapter's tool each message is.
Q1. The TLS 1.3 ClientHello carries the DH public value (key_share) from the very start, alongside the supported versions and cipher candidates. What is this design for?
TLS 1.2 split parameter negotiation and key exchange into separate round trips — two in total. TLS 1.3 has the client include its public value up front, betting it will be acceptable, and key agreement completes the moment the server returns its own. The motive is fewer round trips, not encryption.
Q2. The round-trip time (RTT) between client and server is 100 milliseconds. After the TCP connection is established, how many milliseconds pass at minimum between sending ClientHello and the client being able to send encrypted application data (e.g. an HTTP request)?
ClientHello (out) → ServerHello through Finished (back) is one round trip = 100 ms. The client can start sending application data together with its own Finished. TLS 1.2 needed two round trips (200 ms). That difference is what "TLS 1.3 = 1-RTT handshake" means.
Q3. What does the server's CertificateVerify do?
As Chapter 4 showed, certificates are public and copyable. So the server signs the whole handshake so far — content that exists only in this session, impossible to precompute or replay. That is the proof of private-key possession, the move that finally cuts off impersonation.
After the handshake — the shared secret is not used raw
Two details that matter in real conversations:
Keys are derived per purpose. The Chapter 3 shared secret is not used directly; it passes through a key-derivation function (HKDF) to produce separate keys per direction and purpose — client→server, server→client, and so on. Deriving role-specific keys from one secret limits the blast radius if any one key is analyzed.
Encryption and tamper detection run as one. Traffic is protected by authenticated encryption (AEAD, e.g. AES-GCM), which performs encryption and integrity checking (Chapter 2's MAC role) in a single operation. The combination accident "encrypted, but forgot the MAC" is structurally impossible.
There is also session resumption: a returning client can use a ticket (PSK) to lighten the next handshake. Resumption enables 0-RTT — data in the very first flight — but that flight alone cannot be protected against replay (an attacker re-sending the same data), so it is reserved for operations that are harmless if executed twice, like plain GETs.
Practice 5-2 — Reading the design intent
These ask "why is it built that way?" — and pay off a Chapter 1 foreshadowing.
Q4. In TLS 1.3, in what state does the server's Certificate message travel the wire?
Once ClientHello and ServerHello have exchanged public values, both sides can compute the shared secret. TLS 1.3 derives keys right away and encrypts everything after ServerHello, certificate included (in TLS 1.2 the certificate traveled in plaintext). One payoff of moving key agreement to the front.
Q5. What is the role of the Finished messages both sides exchange at the end of the handshake?
Finished is a keyed verification value computed over the transcript of every handshake message. If an on-path attacker had, say, deleted the strong cipher candidates to force a weak one, the two transcripts would disagree and it surfaces here. Think of it as comparing fingerprints of the meeting minutes at the end. Despite the name, it is not a goodbye.
Q6. Chapter 1 noted that even with HTTPS, the destination domain name is visible on the path. Why?
A server hosting many domains on one IP must learn which certificate to present, first thing. So the host name (SNI) rides in the ClientHello — a message from before key agreement, with nothing to encrypt it with. That is the mechanism behind Chapter 1's observation (an extension that encrypts it, ECH, is gradually spreading).
What to take from this chapter
- TLS 1.3 puts the public value in the ClientHello and finishes the handshake in one round trip; the certificate onward is already encrypted
- CertificateVerify = signature over this session's content = proof of private-key possession. Finished = tamper detection over the whole handshake
- Keys are derived per purpose via HKDF; traffic uses AEAD, encryption and integrity as one
- SNI travels before key sharing, so it is visible; 0-RTT is fast but replay-prone
That completes one full pass over the mechanism. Next, we observe everything above in the wild — with openssl and a browser.