How the TLS Handshake Works: What Your Browser Does Before Loading Any HTTPS Page

Every time you load an HTTPS website, your browser and the server go through a sequence of exchanges before a single byte of webpage content is transferred. This is the TLS handshake, and it is responsible for establishing an encrypted, authenticated connection. Here is what actually happens.

Why the Handshake Is Necessary

The goal of TLS is to achieve two things simultaneously: confirm you are talking to the legitimate server (authentication), and establish a shared secret key for encrypting the conversation (key exchange). Neither of these can happen without some back-and-forth first. You cannot encrypt something until you have agreed on how to encrypt it, and you need to verify the other party is who they claim to be before trusting them with anything sensitive.

TLS 1.2 Handshake: Two Round Trips

In TLS 1.2, the handshake requires two full round trips before encrypted data can flow. First, the client sends a ClientHello with the TLS versions it supports, a random value, and a list of cipher suites it can use. The server responds with a ServerHello choosing a specific version and cipher, its certificate (containing the public key), and its own random value. The client verifies the certificate against trusted certificate authorities, generates a pre-master secret, encrypts it with the server public key, and sends it. Both sides independently derive the same session keys from the pre-master secret and the random values. Then both send a Finished message encrypted with the new session key, confirming the handshake succeeded. Only now can application data flow.

TLS 1.3: One Round Trip

TLS 1.3, finalized in 2018 and now widely supported, streamlines this to a single round trip. The client sends its ClientHello with key shares for the most likely key exchange algorithms alongside its cipher suite list. The server can respond immediately with its own key share, certificate, and a Finished message — already using the negotiated encryption. The client can send its own Finished message and start sending encrypted application data in the same flight. This shaves a full round-trip of latency off every new HTTPS connection.

Certificate Verification: How Authentication Works

The server certificate is central to TLS authentication. It contains the server public key and is signed by a Certificate Authority (CA) the browser already trusts. The browser ships with a list of trusted root CAs — around 150 of them. When it receives the server certificate, it verifies the CA signature and checks that the certificate covers the hostname it connected to, has not expired, and has not been revoked.

This is the chain of trust: browser trusts root CA, root CA signed an intermediate CA, intermediate CA signed the server certificate. Most server certificates are issued by intermediate CAs, not directly by roots, so the server typically sends the full chain including intermediate certificates during the handshake.

Session Resumption and 0-RTT

If you recently visited a site, TLS 1.3 supports session resumption that reduces a second connection to zero additional round trips — the client includes a session ticket from the previous connection in its first message, and the server can respond with encrypted data immediately. This is called 0-RTT resumption. It comes with a trade-off: 0-RTT data can be replayed by an attacker, so it should only be used for idempotent requests like GET, never for state-changing actions like form submissions or purchases.

What All This Costs in Practice

On a typical broadband connection to a server 50 ms away, a TLS 1.3 handshake adds about 50–100 ms to the initial connection — one round trip at network speed. TLS 1.2 adds 100–200 ms. Session resumption reduces this to near zero for repeat visits. For CDN-served content where the edge server is physically close to the user, handshake latency can be under 10 ms.

The computational cost of TLS on modern hardware is negligible. AES encryption is hardware-accelerated on virtually all current CPUs. The latency cost of the handshake is the real consideration, not CPU load.