How TLS 1.3 works

You type https://example.com into your browser. The first thing your browser does — before sending a single byte of the request, before even confirming the server is who it says it is — is agree on a shared secret with a complete stranger over an open network.

This is the impossible-sounding feat that Diffie and Hellman solved in 1976 and that Daniel Bernstein modernized in 2005 with Curve25519. The browser picks a random private key, computes the public key (one elliptic-curve scalar multiplication, ~30 microseconds), and sends the public key to the server in the ClientHello. The server does the same and replies in the ServerHello. Both sides now multiply their own private key by the other's public key, and — by the algebra of the curve — get the same 32 bytes. An attacker watching the wire sees both public keys and can't compute the shared secret.

TLS 1.3 mandates X25519 (or P-256) for this step; the older RSA key-exchange ciphersuites from TLS 1.2 are GONE — no forward secrecy was the deal-breaker. With X25519, the private keys are ephemeral (generated fresh per connection, discarded after), so even if the server is compromised tomorrow, recorded traffic from today can't be decrypted retroactively. That's forward secrecy, and it falls out for free from making the key exchange ephemeral.

32 bytes of shared secret. Now what?

TLS 1.3 feeds it into HKDF (extract-then-expand) to derive a tree of working keys: a client_application_traffic_secret, a server_application_traffic_secret, IVs, exporter secrets, resumption secrets. From each traffic secret, HKDF-Expand produces a concrete AEAD key + initial IV.

The actual record encryption is AES-128-GCM or ChaCha20-Poly1305 (the client advertises preference; on mobile, where AES-NI isn't available, ChaCha20 wins because it's faster in software). Both are AEAD constructions — they encrypt and authenticate in one pass. Every record gets its own nonce (derived from the IV XOR the sequence number), and the 16-byte tag at the end catches any tampering. Flip a bit in transit and decryption throws InvalidTag.

Why two AEADs and not just AES-GCM? Diversity. If a flaw is found in AES-GCM's tag (Joux's forbidden-attack class) or in GHASH polynomial arithmetic, ChaCha20-Poly1305 is the drop-in replacement using a structurally different MAC (polynomial in a prime field, not Galois field). The internet doesn't have to wait for a panic redeploy.

We've got a confidential, integrity-protected channel. But to who? X25519 establishes a shared secret with some entity — there's nothing stopping an attacker from doing the key exchange themselves and serving you a fake example.com. The browser needs to verify identity.

After the key exchange, the server sends a Certificate message: an X.509 certificate chain signed by a Certificate Authority the browser trusts. Modern certificates use Ed25519 or ECDSA P-256 signatures on the leaf cert (RSA-2048 is still common but shrinking; the CA roots are still mostly RSA). The browser verifies the chain: leaf signed by intermediate, intermediate signed by root, root in the trust store.

Then the server signs a CertificateVerify: an Ed25519 signature over a transcript hash of every handshake message so far. This proves the server holds the private key matching the public key in its certificate AND that it saw the same handshake bytes the client did (no man-in-the-middle splicing). The browser verifies. Handshake complete.

Total round trips for a fresh TLS 1.3 connection: one. ClientHello and ServerHello + Certificate + CertificateVerify + Finished happen in 1.5 RTT. If the client and server have a pre-shared key from a prior session, it's zero RTT — the first application data byte can ride in the ClientHello.