how/network

TLS handshake: how a browser negotiates with a server

The green padlock in the browser does not appear right away. Before it, a few packets pass where the two sides pick a cipher, check the certificate, and compute a shared key.

When you open https://example.com, before the page content shows up in the browser, the client and server have to agree on an encrypted channel. That is the TLS handshake.

It settles several things at once:

which cipher suite to use (which encryption algorithms)
the server authenticates itself with a certificate (it proves "I really am example.com")
the two sides compute a shared session key for symmetric encryption (without sending the key itself over the network)

Press ▶ to see how all of this happens in 3 packets (TLS 1.2; 1.3 is trickier, everything in 1 round-trip, but the idea is the same).

step 1/7·00 · TCP is already set up, starting TLS

§ steps

Before TLS there has to be a ready transport channel: a TCP connection in ESTABLISHED (see tcp-handshake).

On top of that channel a separate handshake begins. Now you negotiate the encryption. Until it finishes, no HTTP data is sent, only internal TLS messages.

recap

What to remember:

TLS runs on top of TCP (see tcp-handshake). TCP is established first, then TLS on top of it. The first HTTP message is sent only after the TLS handshake
In ClientHello the client sends SNI (Server Name Indication), the domain name. This is needed because one IP can host many HTTPS sites, and the server has to know which certificate to return
A certificate is a public key plus a CA signature. The server holds the private key for that certificate, and that is what proves it is "real" (only the holder of the private key can decrypt what was encrypted with the public one)
The session key is not sent over the network. It is computed by both sides from the exchange. Modern ciphers use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). Even if someone recorded the whole handshake, they cannot decrypt the data later. This is called forward secrecy
TLS 1.3 cut the handshake down to 1-RTT (one round-trip): ClientHello already carries the key material, the server replies right away with its ChangeCipherSpec + Finished, then comes the data. Much faster
If you want to get your hands dirty, there is a lesson intermediate-09-tls- handshake that walks through a real pcap from tcpdump

Related to the [[tls-handshake|extended KB article]] and to the next explainer on HTTPS cert chain validation: what happens when the browser checks the certificate.

§ dig into the knowledge base

§ try it hands-on

intermediate-09-tls-handshake- TLS handshake: look at the pcap

§ steps

Before TLS there has to be a ready transport channel: a TCP connection in ESTABLISHED (see tcp-handshake).

On top of that channel a separate handshake begins. Now you negotiate the encryption. Until it finishes, no HTTP data is sent, only internal TLS messages.