Every HTTPS request starts with a negotiation most engineers never watch. TLS 1.3 turned that negotiation from a chatty back-and-forth into a single confident move — and shaved a full round trip off every secure connection on the planet.
What the handshake has to accomplish
Before a single byte of your request is safe to send, the handshake must achieve three things at once: agree on a cipher both sides support, derive a shared secret no eavesdropper can compute, and authenticate the server so you know you're talking to the real site and not an impostor. TLS 1.2 did these in sequence over two round trips. TLS 1.3's whole design is doing all three in one. Keep those three goals in mind and every message below has an obvious purpose.
The bet that saves a round trip
TLS 1.2 needed 2 round trips: the client says hello, the server picks parameters, then they exchange keys. TLS 1.3 collapses this to 1-RTT with a gamble — the client guesses the key-exchange group and ships its public key share inside the very first ClientHello.
ClientHello → supported ciphers, key_share (X25519 public key),
supported groups, SNI (which host)
← ServerHello: chosen cipher, server key_share,
{EncryptedExtensions, Certificate, CertificateVerify, Finished}
Finished → client verifies, sends its own FinishedFor X25519 the guess is almost always right, because it is the overwhelmingly common choice. The server returns its own share in ServerHello, and after that single exchange both sides have everything they need. If the client guesses a group the server won't accept, the server sends a HelloRetryRequest asking for a different one — costing the extra round trip — but in practice that path is rare.
How the shared secret is born
Neither side ever transmits the actual session key. Each combines its private key with the peer's public share via Elliptic-Curve Diffie-Hellman (ECDHE) and computes the same raw secret independently. An eavesdropper who captures both public shares still cannot derive it without one of the private keys — that's the whole magic of Diffie-Hellman.
That raw secret feeds HKDF — extract, then expand — deriving a hierarchy of keys bound to the running handshake transcript. Because the keys are welded to a hash of every prior message, tampering with any earlier byte makes both sides compute different keys and the handshake collapses — so downgrade protection comes for free. Better still, everything after ServerHello is encrypted, including the certificate. TLS 1.2 sent certs in the clear, leaking which site you visited to anyone watching; TLS 1.3 does not.
Forward secrecy, and why it matters
Because every session generates a fresh ephemeral ECDHE key pair that is thrown away afterward, TLS 1.3 gives you forward secrecy by default. Capture and store all of today's encrypted traffic, steal the server's long-term private key a year from now, and you still cannot decrypt what you recorded — the ephemeral keys that actually protected those sessions no longer exist anywhere. TLS 1.2 allowed non-forward-secret cipher suites (plain RSA key exchange) where stealing that one key unlocked years of captured traffic. TLS 1.3 removed them entirely. This is a direct answer to "harvest now, decrypt later" surveillance.
Authentication: proving it's really them
Deriving a shared key with someone is worthless if that someone is an attacker in the middle. The Certificate and CertificateVerify messages close that gap. The server presents its certificate chain, and in CertificateVerify it signs the entire handshake transcript with the private key matching the certificate — proving it holds the key, not just a copy of someone's cert. The client validates the chain up to a trusted root CA, checks the hostname and expiry, and only then trusts the connection. Key agreement gives you secrecy; this step gives you identity.
0-RTT: speed with a sharp edge
For repeat visitors, TLS 1.3 offers 0-RTT — early data sent with the first packet using a pre-shared key (PSK) from a prior session. Zero handshake latency before the first request byte; the client starts sending application data immediately.
The catch is fundamental, not an implementation bug: 0-RTT data has no replay protection. The client sends it before any fresh exchange with the server, so there is no server-provided randomness to bind it to this moment. An attacker who captures that early-data flight can resend it later, and the server has no freshness with which to reject the duplicate.
0-RTT rule of thumb:
GET /products -> safe (idempotent, no side effect if replayed)
POST /transfer -> NEVER (a replay moves money twice)Keep early data strictly idempotent, or skip it. The performance win is real, but it is only safe for requests that cause no harm when repeated.
The takeaway
- Three jobs, one round trip — TLS 1.3 agrees a cipher, derives a key, and authenticates the server in a single exchange.
- 1-RTT by guessing right — the client front-loads its key share, killing a full round trip versus TLS 1.2.
- HKDF + ECDHE derive the session key locally and weld it to the transcript; certs ride encrypted, and downgrade protection is automatic.
- Forward secrecy by default — ephemeral keys mean a future key theft can't decrypt today's captured traffic.
- 0-RTT is fast and dangerous — never let replayable, state-changing requests use it.