What Changed In TLS 1.3

Last section we ended on a problem. The TLS 1.2 handshake takes two full round trips before any HTTP data flows. Add TCP and you're at 3 RTTs of pure protocol overhead before the first byte of HTML arrives. For a user in Berlin talking to a server in São Paulo at 200ms RTT, that's 1.2 seconds of waiting before the page even starts.

In 2018, after four years of work and 28 drafts at the IETF, TLS 1.3 finally shipped as RFC 8446. It cut the handshake in half, removed every cryptographic primitive that had ever caused a real-world attack, and made several previously-optional security features mandatory.

As of 2026, TLS 1.3 carries roughly 73% of all encrypted web traffic. TLS 1.2 still runs the rest, mostly on older enterprise stacks. Anything older — TLS 1.0, 1.1, SSL 3.0 — is deprecated and disabled by default in every modern browser.

The Big Idea — Combine The Round Trips

Recall the TLS 1.2 problem. The first round trip is negotiation — "what versions and ciphers can we both speak?" The second round trip is key exchange — "now let's agree on a shared secret." TLS 1.3 collapses these by doing both at once.

In TLS 1.3, the client doesn't politely wait for the server to pick a cipher. It guesses. It sends an ephemeral Diffie-Hellman key share for the most likely cipher suite right inside the ClientHello. The server, on its side:

• Picks a cipher suite from the client's list;
• Generates its own ephemeral key share;
• Computes the shared secret immediately;
• Encrypts the certificate, signature, and Finished message;
• Sends them all back in one shot.

The client verifies, sends its own Finished, and immediately follows up with the actual HTTP request. One round trip total.

If the client guessed the wrong cipher and the server doesn't support the offered key share, TLS 1.3 falls back to a "HelloRetryRequest" — a second round trip. But this almost never happens in practice. Modern clients all support the same handful of key shares (mostly X25519), and servers pick from this same small list.

The 100-Millisecond Win

That extra round trip TLS 1.3 removes is worth real money:

• On a 100ms RTT connection (typical mobile), TLS 1.3 saves 100ms per new HTTPS connection;
• On a 200ms RTT connection (intercontinental), it saves 200ms;
• For a website that loads 30 third-party scripts (analytics, ads, fonts, CDNs), each on a fresh TLS connection, the savings can stack into a full second of page load time.

Faster handshakes mean less battery on mobile, less CPU on the server, and pages that feel snappier to humans. This alone would have been worth the upgrade.

What Got Deleted

TLS 1.3 didn't just speed up the handshake. It also took an axe to TLS 1.2's huge surface area of legacy cryptography. Every primitive that had ever caused a real-world attack got removed:

• RSA key exchange — gone (no Perfect Forward Secrecy, broken when the server key leaks);
• Static Diffie-Hellman — gone (same reason);
• CBC mode ciphers — gone (BEAST, Lucky 13, padding oracle attacks);
• RC4 — gone (had statistical biases that broke its security);
• 3DES — gone (too weak, Sweet32 attack);
• MD5 — gone (collision-broken);
• SHA-1 — gone (also collision-broken);
• Compression — gone (CRIME attack);
• Renegotiation — gone (caused several attacks).

The list of supported cipher suites went from over 300 in TLS 1.2 down to just 5 in TLS 1.3. Less choice means less to misconfigure. We'll dissect those 5 in the next chapter.

The Certificate Is Now Encrypted

In TLS 1.2, the server's certificate was sent in the clear during the handshake. Anyone watching the wire could see exactly which certificate (and therefore which identity) the server was presenting. This wasn't a confidentiality disaster — certificates are public — but it leaked metadata.

In TLS 1.3, everything after the ServerHello is encrypted, including the certificate. An eavesdropper sees that "someone connected to some server" but can't tell which certificate was used. The only thing still in the clear is the Server Name Indication (SNI) — the domain in the ClientHello — and that's exactly what Encrypted Client Hello (ECH) fixes. More on that in Chapter 6.

PFS Is Not Optional Anymore

In TLS 1.2, Perfect Forward Secrecy (PFS) was optional. You had to deliberately choose a cipher suite starting with ECDHE or DHE to get it. Many servers shipped with RSA key exchange enabled, meaning a future leak of the server's private key would decrypt every past conversation.

TLS 1.3 makes PFS mandatory. Every key exchange is ephemeral. Every session uses fresh keys. There is no way to negotiate a non-PFS cipher. We'll dig into what this actually means in Chapter 3.

0-RTT — The Magic-But-Dangerous Feature

TLS 1.3 also adds 0-RTT (zero round trip time) for returning clients. If you've connected to a server before, you can send the HTTP request in the very first packet of the new connection — before the handshake completes. Zero round trips of wait.

This is brilliant for performance. It also has a catch — replay attacks. We'll cover both sides in Chapter 6.

What's Next

Now that you know what TLS 1.3 changed, the next chapter dives into the cipher suite names you'll see in every modern config. By the end of it, you'll be able to read TLS_AES_256_GCM_SHA384 like a sentence.