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.
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.