PlayInfoBox

Home /Education /The TLS Handshake, Step by Step

The TLS Handshake, Step by Step

Every padlock icon in your browser represents a handshake that happened in a fraction of a second before a single byte of your actual data was sent.

How HTTPS and TLS relate

HTTPS is ordinary HTTP traffic encrypted with TLS (Transport Layer Security). Before any real data moves, the browser and server complete a negotiation called the TLS handshake to safely agree on the keys they'll use to encrypt everything that follows.

Step 1: ClientHello

The browser starts the exchange by sending the TLS versions and cipher suites (encryption methods) it supports, along with a random value, proposing how it would like to communicate.

Step 2: ServerHello and certificate

The server picks one of the proposed options and replies with a ServerHello, then sends its SSL/TLS certificate to prove it's the site it claims to be.

Step 3: Key exchange and session key

After verifying the certificate, the browser and server use public-key (asymmetric) cryptography to safely exchange values, then both independently compute the same symmetric session key that will actually encrypt the connection.

Step 4: Finished, encryption begins

Both sides exchange a 'Finished' message confirming that nothing exchanged so far was tampered with in transit. From this point on, every byte of data is encrypted with the session key they just created.

Why TLS 1.3 is faster

TLS 1.2 needed two full round trips (2-RTT) to complete a handshake, while TLS 1.3 streamlined the negotiation down to a single round trip (1-RTT), and can resume a previous connection in zero round trips (0-RTT) for an even faster reconnect.

Why the Handshake Happens Before Any Data Loads

This entire negotiation happens before your browser requests the actual webpage, which is why a slow or failing handshake β€” due to an expired certificate, an unsupported cipher suite, or network issues β€” can make a site fail to load even though the server itself is running fine. Browser 'connection is not private' warnings are almost always a handshake-stage failure, not a problem with the page content itself.

Public-Key vs. Symmetric Encryption in One Handshake

The handshake actually uses two different kinds of cryptography for two different jobs: slower but more secure public-key encryption to safely exchange the initial secret without anyone eavesdropping, and then fast symmetric encryption using the resulting session key for the actual data transfer, since symmetric encryption is far more efficient for the large volume of data an ordinary web session carries.

Frequently Asked Questions

Why did TLS 1.3 remove a round trip compared to TLS 1.2?

TLS 1.3 simplified the handshake by having the client propose a specific key-exchange method upfront, letting the server respond with everything needed to finish the handshake in a single round trip instead of two.

Does a faster handshake actually make a noticeable difference to page load speed?

Yes, especially on high-latency connections like mobile networks β€” since a full round trip can take anywhere from tens to hundreds of milliseconds, cutting the handshake from two round trips to one (or zero, on a resumed connection) measurably speeds up how quickly a secure page starts loading.