TLS 1.3 Handshake
Prompt
Walk me through a TLS 1.3 handshake — how the client and server end up with a shared key in a single round trip — and what the certificate is actually proving along the way.
How this round runs
This is a conversation that escalates — I'll keep asking "and what happens when…" until I find the edge of what you know. I want the 1-RTT mechanism and an honest account of what certificate validation really checks — then I'll push into 0-RTT's replay risk, which is the trade everyone forgets.
Model answer
I'll trace the 1-RTT flow, then say what the certificate proves, because the two are
separate guarantees. In TLS 1.3 the client's ClientHello is optimistic: it includes a
key-share — its half of an (elliptic-curve) Diffie-Hellman exchange — guessing the group the
server will accept. The server replies ServerHello with its own key-share, and now both
sides can derive the shared secret from the DH exchange; everything after that in the same
flight — the server's certificate, its signature over the handshake transcript, and the
Finished — is already encrypted. That's the 1-RTT win: one round trip and application data
can flow, versus TLS 1.2's two. The ephemeral DH per session is also why forward secrecy is
mandatory in 1.3 — stealing the server's long-term private key later doesn't decrypt past
captured sessions, because that key never directly encrypted the traffic.
What the certificate actually proves is narrower than "this is secure," and this is where I'm precise. Validation checks three distinct things: a chain of trust — the cert is signed by an intermediate signed up to a root in the client's trust store; validity — not expired, not revoked (OCSP/CRL); and crucially name binding — the hostname matches the cert's SAN. The signature in the handshake then proves the server holds the private key for that cert. What it does not prove is that the operator is honest or the site benign — only that you're talking to whoever controls the private key for that validated name. My honest boundary: revocation in practice is weak (CRLs are stale, OCSP is often soft-fail), so "checked revocation" is more aspirational than guaranteed, and I'd verify a given stack's behavior rather than assume hard-fail.
The edge I'd raise unprompted is 0-RTT. To shave even the first round trip on resumption, 1.3 lets the client send early data encrypted with a pre-shared key from a prior session — but that early data is replayable: an attacker who captures it can resend it, and the server has no handshake freshness to reject the duplicate. So 0-RTT is only safe for idempotent requests; a non-idempotent early request (a purchase, a state change) can be replayed. That's the explicit trade — latency for replay exposure — and it ties straight back to why idempotency matters at the HTTP layer.
- Described the 1-RTT mechanism: optimistic ClientHello key-share → DH shared secret → encrypted cert in the same flight
- Connected ephemeral DH to forward secrecy being mandatory in 1.3, with the 'stolen key can't decrypt the past' reasoning
- Decomposed certificate validation into chain-of-trust, validity/revocation, and name binding — not a vague 'verifies the cert'
- Stated precisely what the cert does NOT prove (operator honesty), only control of the private key for a validated name
- Raised 0-RTT replay risk unprompted and tied it back to idempotency; honest that revocation checking is weak in practice
- 0-RTT shaves the first round trip on resumption — what's the catch? → early data is replayable; only safe for idempotent requests, no handshake freshness to dedupe it
- What does certificate validation actually check, and what does it NOT? → chain of trust + validity/revocation + hostname-to-SAN binding; does NOT prove the operator is trustworthy, only key possession
- Why is forward secrecy mandatory in 1.3, and what would break without it? → ephemeral DH per session; without it, a later private-key compromise decrypts all past captured traffic