TLS: Security's Latency Bill

The last lesson ended on a quiet cliffhanger: HTTP/2 and HTTP/3 refuse to run without encryption. Browsers won't speak them in the clear, and QUIC bakes encryption right into the transport. So on the modern web, encryption isn't a feature you switch on for the login page — it's the floor every request stands on. That raises two fair questions: what does it actually buy you, and what does it cost?

The answer to the second one is the whole reason this lesson exists, and it surprises people:

TLS is nearly free once a connection is running. The entire bill is the handshake at the start — and that bill is paid in round-trips.

Encrypting the actual data is cheap: modern chips do it in hardware, and you'd never notice the overhead. What costs you is the little getting-to-know-you ceremony at the very beginning of a secure connection — the handshake — where the two sides prove who they are and agree on a secret key. Every step of that ceremony is a trip across the network and back, and here's the sting: a round-trip to a server across the ocean takes far longer than one to a server down the street. So the same encryption can be nearly instant or painfully slow, depending entirely on where you are and how you connect.

TLS — Transport Layer Security, the S in HTTPS — is that ceremony. By the end of this lesson you'll know exactly what it buys (it's three things, not one), why the handshake is the bill, precisely where that bill hurts, and the handful of tricks the whole industry uses to shrink it toward zero. It's security, priced in round-trips.

Almost everyone thinks TLS "encrypts your data." It does — but that's only one of three things it provides, and the one people forget is arguably the most important. The cleanest way to hold all three is to picture a sealed, tamper-evident envelope carried by someone whose ID you check:

• Confidentiality — the sealed envelope. The data is encrypted, so anyone watching the network path — your ISP, a coffee-shop Wi-Fi snoop, a router in between — sees only gibberish. They know that you're talking to a server, but not what you're saying.
• Integrity — the tamper-evident seal. Every chunk carries a cryptographic check, so if anyone alters even one byte in transit, the other side notices and rejects it. Nobody can quietly change the numbers in your bank transfer along the way.
• Authentication — the ID check. The server proves it really is who it claims to be. And this is the crucial one: encryption to an impostor is worthless. If an attacker could pose as your bank, a perfectly encrypted conversation would just mean you're securely handing your password to the attacker. Authentication is what slams that door.

How does a server prove its identity? With a certificate — think of it as an ID card. It contains the server's public key and its domain name, and, crucially, it's digitally signed by a Certificate Authority (CA) — a trusted organization your browser and operating system already recognize. Your browser ships with a built-in list of trusted root CAs. When a server presents its certificate, your browser checks the signature chain — the server's leaf certificate was signed by an intermediate, which was signed by a root CA on your trusted list. If that chain checks out, the browser believes the ID. If it doesn't — expired, self-signed, wrong name — you get that alarming red "Not Secure" warning. That whole chain of trust is what makes the padlock in your address bar mean something. Now: how do the two sides set all this up? That's the handshake.

Before a single byte of your actual request can go out over a secure connection, the client and server run a short opening ceremony — the TLS handshake — to accomplish three jobs at once:

1. Agree on the rules. They negotiate the TLS version and the cipher (which encryption algorithms to use). This is also where the HTTP version gets chosen — remember ALPN from the last lesson? It rides along inside this handshake. One ceremony, several agreements.
2. Check the ID. The server sends its certificate; the client verifies the chain up to a trusted root CA, confirming it's really talking to the right server and not an impostor.
3. Agree on a secret key. Through a key exchange (using clever asymmetric cryptography), the two sides arrive at a shared symmetric session key that only they know — without ever sending that key across the wire where an eavesdropper could grab it.

Here's the beautiful part, and the key to the whole cost story. That key exchange uses asymmetric cryptography — mathematically heavy, and it requires messages to bounce back and forth between client and server. That's the expensive bit. But once it's done and both sides share the secret key, all the actual data is encrypted with fast symmetric cryptography (like AES), which modern CPUs do in dedicated hardware at essentially no cost.

So the shape of TLS's cost is now clear: a burst of expensive, back-and-forth setup at the very start, then near-free encryption forever after. It's a cover charge at the door, not a toll on every word. Which means the entire question of "how much does TLS cost?" collapses to one thing: how many back-and-forth trips does that opening ceremony take?

Every back-and-forth in the handshake is a round trip — a message out to the server and its reply back — and each one costs you exactly one RTT (round-trip time, the network delay you met in the latency lesson). So counting the round-trips is counting the bill. And this is precisely where the TLS versions differ, and why the newer ones are such a big deal:

• TLS 1.2 — two round trips. The old standard needs two full back-and-forths to finish the ceremony before any data flows.
• TLS 1.3 — one round trip. The clever redesign has the client send its half of the key in the very first message (the ClientHello), so the server can reply with everything it needs in one shot. Half the handshake latency — a saving of roughly 50–100 ms on every new connection, more the farther away the server is.
• TLS 1.3 with 0-RTT resumption — zero round trips. If you've connected to this server before, you both remember a shared key, so the client can send encrypted request data alongside the very first message. The handshake delay vanishes for return visits.

Now stack this on everything else you've learned, because a brand-new HTTPS connection doesn't pay for TLS in isolation — it pays for the whole setup: a DNS lookup, then the TCP handshake (1 RTT), then the TLS handshake on top. Add it up:

To open a new HTTPS connection	Round trips before your first byte
TCP + TLS 1.2	~3 RTT
TCP + TLS 1.3	~2 RTT
HTTP/3 (QUIC)	~1 RTT (or 0 on resume)

And there's the punchline from the last lesson finally paid off: QUIC folds the TCP and TLS handshakes into one, which is a huge part of why HTTP/3 feels so fast. It didn't just fix head-of-line blocking — it also shredded the setup bill. Let's go feel that bill add up.

Round-trips are an abstraction until you watch them cost you real milliseconds — so below, you open a secure connection and the bill tallies in front of you, live.

Start by dragging the distance to the server: a nearby data center, another continent, a satellite link. Watch the exact same handshake go from trivially fast to genuinely painful — because every round-trip costs one RTT, and RTT is just distance. This is the whole "where it hurts" lesson in one slider. Then switch the TLS version — 1.2 (two round-trips), 1.3 (one), 0-RTT resumption (zero) — and watch the time-to-first-byte shrink step by step. Finally, flip on "reuse the connection" and watch the entire handshake disappear: because it's a cover charge at the door, you pay it once, and every request after that skips it entirely. Play with the distance and the version together and you'll feel, in your gut, why the industry obsesses over TLS 1.3, session resumption, and keeping connections warm — and why terminating encryption close to the user matters so much.

You just felt it on the slider, so let's name it precisely. A round-trip's cost is the RTT, and RTT is dominated by physical distance (plus the network in between). That means the identical TLS handshake has a wildly different price depending on where the two ends are:

• Near a data center: an RTT is about 10 ms — a 2-round-trip TLS 1.2 handshake costs ~20 ms. Nobody notices.
• Same continent: ~40 ms per RTT.
• Across an ocean: ~150 ms per RTT — so that same TLS 1.2 handshake now costs ~300 ms, before a single byte of your page arrives.
• Satellite: ~600 ms per RTT — the handshake alone can take over a second.

Same ceremony, same security, a 30× difference in cost — purely from distance. That's the first place TLS hurts: high-latency links (far-away servers, mobile networks, satellite).

The second place is short-lived or brand-new connections. The handshake is a fixed setup cost. If a connection opens, sends one tiny request, and closes, the handshake is nearly the entire time. But if the same connection stays open and serves a hundred requests, that one-time cost gets amortized into nothing — a rounding error across all those requests. So TLS is brutal on "connect, one request, disconnect" patterns and almost invisible on long-lived, busy connections.

Put those two together and you have a precise diagnosis: TLS's latency bill hurts most when RTT is high AND connections are new or short-lived — a user in Australia hitting an origin server in Virginia, opening a fresh connection for every little thing. Which is exactly the situation the next section's tricks are designed to fix.

Since you can't skip TLS on the modern web, the entire game is making the handshake cheap. Here is the industry's toolkit, roughly in order of impact — and notice that most of them attack one of the two pain points you just learned (high RTT or new connections):

• Use TLS 1.3. One round-trip instead of two. Free 50% cut to the handshake, just by using the modern version. There's no reason not to.
• Reuse connections (keep-alive). Pay the handshake once, then send many requests over the warm connection. This is the single most important habit — keep the door open. HTTP/2's one long-lived connection is fantastic for exactly this.
• Session resumption & 0-RTT. A returning visitor can skip the full handshake (session tickets) or even send data immediately (0-RTT). On a big network like Cloudflare, ~40% of TLS sessions are resumptions — an enormous real-world saving.
• Terminate TLS at the edge. This is the big architectural one. Put the TLS endpoint physically close to the user — at a CDN's edge location a few milliseconds away — so the expensive handshake round-trips happen over a tiny RTT. The edge then talks to your far-away origin over an already-warm, reused connection. This is the reason a global site with full encryption still feels instant from anywhere: the round-trips that cost the most happen over the shortest distance. (You'll meet the box that does this — the reverse proxy — in the very next lesson.)
• OCSP stapling. Normally the browser might make a separate trip to the CA to check the certificate hasn't been revoked. Stapling has the server attach that proof to the handshake itself, eliminating an extra round-trip.
• Modern certificates (ECDSA). Smaller keys, faster math than old RSA.

The through-line: the data encryption was never the problem — the setup round-trips are. So every trick either removes a round-trip (1.3, 0-RTT, stapling), avoids paying it again (reuse, resumption), or makes each one cheaper (edge termination shrinks the RTT). Do these, and TLS goes from a scary "security tax" to a cost you genuinely stop thinking about.

Two of these have teeth, and a good engineer knows where they bite.

0-RTT's dark side: replay attacks. Zero round-trips sounds like pure free speed — but there's a catch that follows directly from how it works. Because 0-RTT data is sent before the handshake finishes, the usual protections aren't fully in place yet, which means an attacker who captures those early encrypted packets can replay them — send the exact same request to the server again. For a harmless GET ("load the homepage"), replaying it does no damage. But imagine the request was "transfer $100" — replaying it three times transfers $300. So the rule is firm: 0-RTT is only safe for idempotent requests (ones that do the same thing no matter how many times you send them, like reads) and must be disabled for anything that changes state — payments, logins, posts. Free speed, but with a sharp edge you have to respect. It's a perfect little reminder that every optimization is a trade-off.

Certificate expiry: the self-inflicted outage. Certificates expire — often every 90 days now. And an expired certificate isn't a gentle degradation; it's a hard outage. Every visitor's browser throws a full-screen security error and refuses to load your site — even though your servers are perfectly healthy, your code is fine, and nothing actually broke except a date. This is one of the most common and most embarrassing outages in the entire industry; giant companies have taken themselves down this way. The fix is purely operational and non-negotiable: automate renewal (the ACME protocol, e.g. Let's Encrypt, renews certs for you) and monitor expiry dates so a human gets warned long before the deadline. (It's the same lesson as "it's always DNS" from earlier — the thing that takes you down often isn't your servers; it's a certificate or a config.) And while we're here: TLS 1.0 and 1.1 were deprecated in 2021 — old, insecure, and rejected by modern browsers. Use TLS 1.2 at minimum, 1.3 by default.

The trade-off at the heart of TLS is clean and, unusually, mostly one-sided:

Security (confidentiality + integrity + authentication) costs you setup latency — a burst of handshake round-trips per new connection.

What makes it mostly one-sided is that on the modern web you don't actually get to choose the "cheap, insecure" option — browsers, HTTP/2, HTTP/3, APIs, and users all demand encryption. So the real decision isn't whether to pay; it's how to make the bill small. And you now know the whole answer: newer TLS (1.3), reuse connections, resume sessions, terminate at the edge, staple OCSP. Every one of those shrinks the handshake without giving up a shred of security. That's the rare trade-off you can almost win outright — full security at a cost you engineer down to near zero.

But nested inside it is a sharper trade you can't dodge: 0-RTT trades a round-trip for replay risk. You buy the fastest possible start, and you pay by restricting it to requests that are safe to replay. That one you have to make consciously, per endpoint.

The mental model that ties it all together — and that you should carry into every system you design — is the cover charge: TLS is a one-time fee at the door, not a per-word toll. Encryption of the actual conversation is nearly free; the only real cost is getting in. So the winning move is never "avoid the club" — it's "keep the door open" (reuse connections) and "put the door close to the guests" (terminate at the edge). Do that, and security stops being a latency problem at all.

"TLS/HTTPS makes everything slower." No — the handshake is the only real cost, paid once per new connection. The bulk encryption is symmetric AES in hardware — nearly free. Steady-state HTTPS is about as fast as plain HTTP.

"TLS just encrypts your data." It does three things: confidentiality (encrypt), integrity (detect tampering), and authentication (the certificate proves the server's identity — the part that stops you from securely talking to an impostor).

"The certificate is the encryption key." No — the certificate is an ID document (public key + owner, signed by a CA). The actual session key is negotiated during the handshake and is symmetric.

"TLS 1.3 is just a security update." It's also a major performance win: one round-trip instead of two, plus 0-RTT resumption — roughly half the handshake latency.

"0-RTT is free speed — always enable it." 0-RTT data is replayable by an attacker → safe only for idempotent requests (a GET); never for payments or logins.

"TLS costs the same everywhere." It's dominated by RTT — the identical handshake costs ~20 ms near a data center and ~300 ms across an ocean. It hurts most on high-RTT and short/new connections, which is exactly why you terminate TLS at the edge.

"A certificate is set-and-forget." Certs expire (often every 90 days); an expired cert is an instant, total outage on perfectly healthy servers. Automate renewal (ACME) and monitor expiry.

Five minutes and you'll see the handshake bill as a real slice of time on your own connections. Predict first: for a site hosted far away versus one behind a nearby CDN, how much bigger do you think the TLS portion of the connection setup will be?

1. Spot it in DevTools. Open DevTools → Network, click any HTTPS request, and open the Timing tab. You'll see the setup broken into slices: DNS Lookup, Initial Connection (the TCP handshake), and SSL (that's the TLS handshake). That SSL slice is the bill — the round-trips you've been learning about, in milliseconds.
2. Measure it from the terminal. Run curl -w "tcp=%{time_connect} tls=%{time_appconnect}\n" -o /dev/null -s https://example.com. The gap between tcp (TCP done) and tls (TLS done) is the TLS handshake time. Now run it against a site or region far away and watch that TLS number grow — purely because the round-trips got longer. That's "where it hurts," measured.
3. Inspect the ID. Run openssl s_client -connect example.com:443 </dev/null (or click the padlock in your browser). You'll see the certificate chain (leaf → intermediate → root CA) and the negotiated TLS version — hopefully TLSv1.3. You're reading the ID card the server presented to prove it's real.

Do step 2 against a near and a far endpoint and the abstract idea "encryption costs round-trips" becomes a concrete number you watched grow with distance. Once you've seen the TLS slice with your own eyes, you'll never again wonder where a slow first-load went.

Security, priced in round-trips:

• TLS buys three things: confidentiality (encryption), integrity (tamper-detection), and authentication (a certificate signed by a CA proves the server is real — the padlock).
• The cost is almost entirely the handshake: a burst of back-and-forth at the start, then near-free symmetric encryption. A cover charge at the door, not a per-word toll.
• The bill is round-trips: TLS 1.2 = 2, TLS 1.3 = 1, 0-RTT resumption = 0 — and stacked on TCP, a new HTTPS connection is ~3 / ~2 / ~1 RTT, with QUIC folding TCP + TLS into one.
• It hurts most on high RTT (distance) and short/new connections. Shrink it with TLS 1.3, connection reuse, session resumption/0-RTT, edge termination, and OCSP stapling — data encryption itself is nearly free.
• Sharp edges: 0-RTT is replayable → idempotent requests only; expired certs = instant outage → automate renewal.

Notice that the single most powerful trick — terminating TLS close to the user — assumes there's a box sitting between the user and your servers, doing the handshake on your behalf and then forwarding the request onward. That box is one of the most important building blocks in all of system design, and it comes in two flavors that look identical but do opposite jobs: it can hide the client from the server, or hide the servers from the client. That's the next lesson: proxies — forward vs reverse.