How TLS Works - Deep Dive

HTTPS is HTTP over TLS, and TLS is doing three different jobs at once: encrypting your data, verifying nothing was tampered with, and proving the server is who it claims to be. The padlock icon in your browser means all three succeeded. But that success comes with a cost, and the cost is usually not what you think. The CPU overhead of encryption is small on modern hardware. The real problem is round trips. Every secure connection starts with a multi-message negotiation before the first byte of your actual request can flow, and on a high-latency network, those round trips add up fast.

This is why your first HTTPS page load can feel slow, but subsequent navigations to the same site feel instant. It's also why CDNs help, why TLS 1.3 was a big deal, and why bad certificate configuration can affect performance even on a fast network.

TLS solves confidentiality, integrity, and authentication together. Confidentiality means attackers can't read your traffic. Integrity means they can't modify it without detection. Authentication means the client can verify it's talking to the real server, not an impostor sitting in the middle.

Encryption alone is not enough. If you generate a random key pair and encrypt traffic with it, you've solved confidentiality but not authentication. An attacker on the network path can intercept your connection, present their own key, and sit invisibly between you and the server. They decrypt your traffic, read or modify it, re-encrypt it with the server's key, and forward it along. You see encryption, but you're talking to the wrong endpoint. TLS stops that by requiring the server to prove its identity with a certificate signed by a trusted authority.

When you load https://example.com/account?token=abc123, TLS protects the entire HTTP exchange: the request method, the path, the query string, all headers including cookies and authorization tokens, and the response body. Without TLS, anyone on the network path-your ISP, a coffee shop router, a compromised middlebox-can read and modify everything. That includes session cookies, which means an attacker can hijack your login without ever seeing your password.

TLS also prevents silent modification. Without integrity protection, an attacker could inject <script> tags into HTML responses, redirect payment forms to phishing sites, or alter API responses. TLS makes that cryptographically detectable.

TLS uses asymmetric cryptography to bootstrap trust and symmetric cryptography to protect bulk data. Asymmetric crypto (like RSA or elliptic curve) lets two parties who have never met establish a shared secret over an untrusted channel, but it's computationally expensive. Symmetric crypto (like AES-GCM) is orders of magnitude faster, but both sides need the same secret key. TLS uses the former to establish the latter: the handshake does expensive public-key operations once, derives a shared session key, and then encrypts all application traffic with fast symmetric algorithms. That's the entire design in one sentence.

A TLS certificate is a digitally signed document that binds a public key to a hostname. The server keeps the corresponding private key secret. The certificate contains the public key, identity information like the domain name, validity dates, and a digital signature from a certificate authority (CA). When your browser connects to example.com, the server presents a certificate claiming "this public key belongs to example.com," and the CA's signature vouches for that claim.

Think of it as an identity card, but verified by math instead of a human looking at it. The server proves it owns the private key by signing data during the handshake. The browser verifies the signature using the public key in the certificate, and verifies the certificate itself by checking the CA's signature.

Browsers don't trust individual site certificates directly. They trust a small set of root certificate authorities built into the OS or browser, and those roots vouch for intermediate CAs, which in turn vouch for site certificates. This creates a chain: root -> intermediate -> leaf. The leaf certificate is the one the server presents; the intermediate signs the leaf; the root signs the intermediate.

The chain exists because root CAs rarely sign site certificates directly. Intermediate CAs do the day-to-day issuance work, and if an intermediate is compromised, it can be revoked without replacing every root in every browser in the world. The server sends its leaf certificate and usually one or more intermediates during the handshake. The browser walks the chain up to a root it already trusts.

If the chain is incomplete-say, the server forgets to send an intermediate-some browsers may fail to validate even if the certificate is legitimate. If the chain leads to an untrusted root, the browser shows a certificate error.

Certificate validation is not just "is this signed?" The browser checks:

If any check fails, the connection is blocked or the user sees a warning. Modern browsers using HSTS may not allow bypassing the warning at all.

You can generate a certificate yourself and use it on your server. It will encrypt traffic just fine. But the browser has no reason to trust it, because it's not signed by a CA in the trust store. The connection is encrypted, but the browser can't prove you're talking to the real server. A man-in-the-middle attacker could present their own self-signed certificate just as easily. That's why self-signed certificates trigger warnings in production. They're fine for local development where you control both ends, but useless for proving identity to strangers on the internet.

The handshake is a multi-message negotiation that establishes shared keys and authenticates the server. RFC 8446 (the TLS 1.3 spec) breaks it into three conceptual phases:

Once these phases complete, the connection switches to using the derived session keys to protect application data. The handshake is the expensive setup; the steady-state encryption afterward is cheap.

The first message is the ClientHello. It includes:

In TLS 1.3, the client sends key shares immediately in the first flight. This is a big change from TLS 1.2, where the key exchange didn't start until the server chose parameters. That extra round trip is gone in 1.3.

The server responds with ServerHello, choosing the TLS version, cipher suite, and key share. If it's a fresh connection, the server also sends EncryptedExtensions, Certificate, CertificateVerify, and Finished. In TLS 1.3, everything after ServerHello is encrypted, even the certificate. This is a privacy win-observers can't see which site you're connecting to by reading the certificate in cleartext.

EncryptedExtensions contains responses to ClientHello extensions that don't affect crypto negotiation, like ALPN. Certificate is the chain of certificates proving the server's identity. CertificateVerify is a signature over the handshake transcript using the server's private key-this proves the server actually controls the key corresponding to the certificate. Finished is a MAC (message authentication code) over the entire handshake transcript, binding everything together.

The client verifies the certificate chain, checks the signature, computes its own Finished MAC, and sends it to the server. Both sides now have the same session keys and can start sending application data.

Every signature and MAC in the handshake covers the exact sequence of messages exchanged so far. This is called transcript binding. It prevents an attacker from silently dropping, reordering, or injecting messages. If a single byte changes anywhere in the transcript, the Finished MACs won't match and the handshake aborts. This makes downgrade attacks and parameter tampering much harder.

Modern TLS uses (EC)DHE key exchange: Elliptic Curve or Finite-Field Diffie-Hellman Ephemeral. Both sides generate temporary key pairs for each connection, exchange public keys, and compute a shared secret. The temporary private keys are discarded after the session ends.

This provides forward secrecy: even if an attacker records all your traffic and later steals the server's long-term certificate private key, they can't decrypt old sessions. The session keys were derived from ephemeral keys that no longer exist. TLS 1.3 removed RSA key exchange (where the client encrypted a secret directly to the certificate key) precisely because it didn't provide forward secrecy. Every modern connection uses ephemeral Diffie-Hellman.

The first handshake to a site is expensive: multiple round trips, certificate chain validation, signature verification. But if you've connected before, TLS can resume the session using keys derived from the previous handshake. This skips most of the expensive parts. The server doesn't resend its certificate chain, and the client doesn't re-verify it. Both sides use a pre-shared key (PSK) from the earlier session to authenticate and derive new traffic keys.

In TLS 1.3, the server can issue a NewSessionTicket message after the handshake completes. Thef ticket is an encrypted blob containing the resumption secret. The client stores it and includes it in the ClientHello of a future connection. If the server accepts the PSK, the handshake is much shorter-no Certificate or CertificateVerify messages.

Resumption is why repeat visits to a site feel fast. The browser reuses the PSK, the handshake completes in one round trip (or zero with 0-RTT), and you don't pay the certificate validation cost again.

TLS 1.2 had two resumption mechanisms: session IDs (server stores state) and session tickets (server sends an encrypted ticket to the client, client sends it back). TLS 1.3 standardized on PSKs and tickets, which scale better because the server doesn't need to keep per-session state. The ticket is self-contained and encrypted with a key only the server knows.

TLS 1.3 introduced 0-RTT resumption. If the client has a PSK from a prior session, it can send application data in the very first flight of the resumed handshake, before waiting for the server's response. This is called early data. It reduces latency by a full round trip, which can be huge on mobile or satellite links.

But 0-RTT has a catch: early data can be replayed. If an attacker captures the first flight, they can resend it. The server can't distinguish a replay from a legitimate retransmission. This is safe for idempotent requests-GET requests that don't change state-but dangerous for anything that mutates data. If a 0-RTT POST request says "transfer $100," replaying it could transfer $100 twice.

Servers that enable 0-RTT must either only allow safe methods, or implement application-level replay protection (like request IDs or nonces). Cloudflare, for example, only allows 0-RTT for GET and HEAD requests by default. The protocol trades some safety for speed, and you need to know what you're trading.

HTTPS is rarely slow because of encryption itself; the main costs are DNS, TCP, and TLS round trips, especially over long distances, plus large certificate chains, multiple origins, and overloaded servers. TLS 1.3, connection reuse, session resumption, compact certificate chains, and CDN edge termination reduce this front-loaded latency, which is most noticeable on the first request.

Terminate TLS at an edge location close to users so the handshake completes with less latency while the edge reuses persistent backend connections and handles session resumption and 0-RTT.

Configure session tickets with reasonable lifetimes, verify that clients successfully resume sessions, and monitor resumption rates to catch silent misconfigurations.

Enable and prefer TLS 1.3 wherever supported because it reduces handshake round trips and simplifies cipher-suite negotiation.

Consolidate resources onto fewer origins, avoid unnecessary domain sharding, and proxy or asynchronously load unavoidable third-party resources so they do not block critical content.

Serve only the leaf certificate and required intermediates, enable OCSP stapling, use modern signature algorithms such as ECDSA with P-256 or RSA 2048+, and remove unnecessary SANs.

Measure handshake latency, full versus resumed connections, and 0-RTT usage in production to identify configuration problems and verify that these features improve performance.

Use HTTP/2 or HTTP/3 to multiplex resources over fewer connections and amortize TLS overhead, with HTTP/3 providing additional benefits through QUIC's integrated transport and cryptographic handshakes.

Enable HSTS and preload the domain when appropriate so browsers skip the HTTP redirect, save a round trip, and resist downgrade attacks.

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.
Y’all are the best.