What happens when you load an HTTPS page
Transport Layer Security (TLS) is the protocol behind the padlock icon, protecting the vast majority of web traffic. A TLS 1.3 handshake (the current version, standardized in 2018) typically completes in one round trip:
1. The client offers supported cipher suites and a key share (an ephemeral ECDHE public value). 2. The server picks a cipher suite, replies with its own key share, and sends its certificate — signed by a Certificate Authority using RSA or ECDSA — plus a signature over the handshake so far. 3. Both sides independently derive the same shared secret via ECDHE, verify the certificate chain, and derive symmetric session keys from that shared secret. 4. All further application data is encrypted with a fast symmetric cipher, almost always AES-GCM or ChaCha20-Poly1305.
TLS 1.3 handshake, one round trip
- 1
Client Hello
Client sends supported cipher suites and an ephemeral ECDHE key share.
- 2
Server Hello + certificate
Server picks a cipher suite, sends its own key share, its certificate chain, and a signature over the handshake transcript.
- 3
Both derive the shared secret
Client and server independently compute the same ECDHE shared secret and derive symmetric session keys from it.
- 4
Certificate verified
Client walks the certificate chain to a trusted root CA before trusting the connection.
- 5
Application data encrypted
All further traffic is encrypted with AES-GCM or ChaCha20-Poly1305 using the derived session keys.
The handshake, as a message exchange
Stripped down to who sends what, a TLS 1.3 handshake is remarkably short — one message each way before application data starts flowing, which is exactly what makes it fast enough to happen on every new connection without a noticeable delay.
Everything after the server's first reply — including the rest of that same flight of messages — is already encrypted, which is why TLS 1.3 leaks less handshake metadata than TLS 1.2 did.
Reading a cipher suite name
A TLS cipher suite's name is a literal recipe, not an opaque label — every component covered elsewhere in this catalog is spelled out in order. Take TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: ECDHE is the key exchange (ephemeral elliptic-curve Diffie-Hellman, giving forward secrecy), RSA is the signature algorithm authenticating the server's certificate, AES_128_GCM is the symmetric cipher and mode protecting application data, and SHA256 is the hash function used in the handshake's HMAC and key-derivation steps.
Reading a suite name this way turns a wall of TLS configuration text into a checklist — anywhere the name says RSA key exchange (not ECDHE) or CBC (not GCM), that's a flag for the migration-checklist and comparison-table modules elsewhere in this catalog.
Practice
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 — how many bits is the symmetric encryption key this suite uses for application data?
Session resumption: skipping the handshake on repeat visits
A full TLS 1.3 handshake is already fast at one round trip, but a returning visitor doesn't even need that: the server issues a session ticket containing a Pre-Shared Key (PSK) derived from the original handshake, and the client presents that ticket on its next connection instead of negotiating a fresh key exchange from scratch. Both sides already share the secret material the PSK was derived from, so there's no new ECDHE exchange or certificate verification to perform — just a quick proof that the client actually holds the PSK.
This is why a second visit to the same site often feels instant compared to the first: the expensive parts of the handshake (asymmetric key exchange, certificate chain verification) only had to happen once, and every resumed connection reuses that earlier work.
Go deeper0-RTT data: the speed comes with a real trade-off⌄
TLS 1.3's most aggressive optimization lets a resuming client send encrypted application data in its very first flight — before the handshake even finishes — called 0-RTT (zero round-trip time) or "early data." The catch, spelled out explicitly in the TLS 1.3 spec, is that this early data has no forward secrecy and, critically, no replay protection: unlike the rest of the handshake, nothing fresh from the server has been mixed into the keys protecting that first flight, so an attacker who captures a 0-RTT packet can resend it verbatim and have it accepted again.
This is exactly why RFC 9846 restricts 0-RTT data to idempotent requests — operations safe to perform more than once, like a GET request — and explicitly warns against using it for anything that changes state, like a purchase or a fund transfer, unless the application layer adds its own replay defense on top.
Practice
A poorly designed payment API accepts 0-RTT early data for a $50 charge request, with no idempotency protection. An attacker captures that 0-RTT packet and replays it 5 additional times, and the server processes every one. Including the original, how many times is the customer charged?
SNI: the metadata leak TLS didn't originally close
Server Name Indication (SNI) is what lets one IP address terminate TLS for thousands of different hostnames — the client includes the hostname it's connecting to in its very first message, so the server (or a reverse proxy in front of many sites) knows which certificate to present before the handshake has established any encryption. That requirement is also the problem: for the entire history of TLS 1.3 up to recently, the hostname in SNI was sent in cleartext, meaning anyone observing the network traffic — including on an otherwise fully "encrypted" HTTPS connection — could see exactly which site a client was visiting, even though the page content itself stayed protected.
Encrypted Client Hello (ECH), standardized as RFC 9849 in March 2026, closes this specific gap by encrypting the entire ClientHello — including SNI — using a public key published in DNS for the destination, so the actual hostname is hidden from network observers as well. Browser and CDN support is already substantial: Chrome, Firefox, and Safari all support ECH by default under common conditions, and Cloudflare, Fastly, and Akamai all support it on the server side.
Every module in this catalog, working together
A single TLS connection is a working demonstration of nearly everything covered elsewhere in this catalog: (ephemeral) Diffie-Hellman for the key exchange, RSA or ECDSA signatures for the server's authentication via its certificate, SHA-2 for hashing throughout the handshake transcript and certificate chain, and AES or ChaCha20 for the actual encrypted data afterward.
This layering is exactly why PQC migration is hard: a TLS deployment isn't "one algorithm," it's a stack of several, each of which needs its own quantum-resistant replacement, and some replacements (like larger PQC key sizes) change performance and packet-size assumptions the whole protocol was tuned around.
Certificate chains and trust
Your browser trusts a server's certificate because it's signed by a Certificate Authority (CA) whose own certificate is pre-installed as a trust anchor. This forms a chain: your leaf certificate is signed by an intermediate CA, which is signed by a root CA your browser already trusts. Break any link — an expired cert, an untrusted CA, a hostname mismatch — and the connection is refused.