Your HTTPS is lying to you. Here's what's actually happening

In 2021, I was running a SaaS with about 8k users. Tiny. Scrappy. Every millisecond mattered because our free trial conversion was dying and I couldn't figure out why.

Turns out we were still on TLS 1.2. Our median handshake time was 400ms before a single byte of actual data moved. On mobile in Southeast Asia, where half our trial signups came from, it was closer to 800ms. Switched to TLS 1.3 in an afternoon. Trial conversions went up 11% that quarter.

So here's what's actually happening when your users connect.

The handshake nobody draws correctly

Your browser and server are strangers. They gotta agree on encryption without ever having met. TLS 1.3 does this in one round trip. One. TLS 1.2 needed two, sometimes three. That's the whole game right there.

Client sends a ClientHello with its supported cipher suites and a key share guess. Server responds with a ServerHello, picks a cipher, sends its own key share, and the certificate. Done. Both sides derive the same session keys using something called the Diffie-Hellman key exchange and they never actually transmit the key. Ever. It's math witchcraft.

Why forward secrecy matters more than your SSL badge

Old TLS used the server's private key to encrypt the session key. Someone records your traffic today, steals your private key next year, they decrypt everything retroactively. TLS 1.3 generates fresh ephemeral keys every single session. Your past sessions stay private even if you get owned later. That's forward secrecy and it's non-negotiable now.

The 0-RTT trap

TLS 1.3 has a feature called 0-RTT resumption. Returning users skip the handshake entirely using a session ticket. Sounds amazing. Kinda is. But it's replay-attack vulnerable. Don't use 0-RTT on anything that mutates state. POST requests with 0-RTT is how you get duplicate orders. I've seen it. It's a bad day.