Primers › Networking

The TLS handshake

Every new HTTPS connection starts with a short exchange called the TLS handshake, before a single byte of the web page moves. It has two jobs:

1. Prove who the server is. The server shows its certificate, and proves it holds the matching private key. Certificates and Trust covers how the browser decides to believe it.
2. Agree on encryption keys that nobody else knows, even though every message of the handshake itself crosses the open internet.

The ideas behind it

Two kinds of keys

The handshake involves two different kinds of keys, used in three places, and keeping them apart makes the rest of this page much easier to follow.

Why not use asymmetric keys for everything? Asymmetric math is much slower than symmetric, so it’s kept for small, one-off jobs like signing and never used to encrypt a whole web page [1]. The handshake uses the slow kind briefly to set up the fast kind, and the fast kind does the rest. Certificates and Trust covers how key pairs and signatures work.

Agreeing on a secret in public

The second job sounds impossible. Two computers that have never met need to end up with the same secret key, while anyone in between can read everything they send. They do it with a key exchange, and the classic way to picture it is mixing paint:

1. Both sides agree, in public, on a common starting color, say yellow.
2. Each side picks a secret color of its own and never shares it. The client picks red, the server picks blue.
3. Each side mixes its secret color into the yellow and sends the mixture across. The client sends orange (yellow + red), and the server sends green (yellow + blue). That mixture is each side’s key share.
4. Each side adds its own secret color to the mixture it received. The client adds red to the green, the server adds blue to the orange, and both end up with the same brown (yellow + red + blue).

In the real handshake, each secret color is a throwaway private key and each key share is its matching public key. That’s a second key pair on each side, separate from the certificate’s, made fresh for every connection and used only to agree on the secret [2].

Each side ends up with brown because it adds its own unmixed secret to the other side's mixture. Someone watching only ever has mixtures.

Making the brown in step 4 takes one mixture plus one unmixed secret color, and only the two ends have one of those. Someone watching saw yellow, orange, and green. If they mix the orange and green together, they get yellow + red + yellow + blue: a brown with twice as much yellow, which is the wrong color, and there’s no way to take the extra yellow back out. They could get the right brown if they could pull the red back out of the orange, but un-mixing paint is impractical, so they can’t.

In the handshake, the client’s key share rides in its very first message and the server’s in its reply, so both sides can make the brown after one exchange. The brown becomes the session key that encrypts the rest of the conversation [2].

Real TLS does this with math instead of paint, where the “un-mixing” step is what’s impractical. For years the usual method has been one called X25519 [3], and newer browsers now pair it with a second method built to resist future quantum computers [4].

Forward secrecy

The secret colors are made fresh for every connection and thrown away afterward. So even if someone records an encrypted conversation today and steals the server’s certificate private key next year, they still can’t decrypt the recording, because the certificate key was only ever used to sign (prove identity), never to protect the session key. That property is forward secrecy, and TLS 1.3 requires it: the older key exchange methods that didn’t provide it were removed [2].

The handshake, step by step

The TLS 1.3 handshake, message by message

A browser opening https://app.example.com sends and receives these messages [2]:

1. ClientHello (client → server, not encrypted). What the client wants and supports:
   • SNI (Server Name Indication): the hostname it wants, so a server hosting many sites can pick the right certificate [7].
   • ALPN (Application-Layer Protocol Negotiation): which protocols it can speak on top, like h2 (HTTP/2) or http/1.1 [8].
   • The TLS versions and cipher suites (sets of encryption algorithms, covered below) it supports.
   • Its key share, the orange paint, sent right away for the method it guesses the server will pick. Browsers guess the method nearly every server supports, and Chrome now guesses the pairing with the quantum-resistant method [4].
2. ServerHello (server → client, not encrypted). The server’s choices from those lists, and its key share. Both sides can now compute the shared secret, and everything after this message is encrypted [2].
3. EncryptedExtensions. The rest of the server’s choices, like which protocol from the ALPN list it picked.
4. Certificate. The server’s certificate chain.
5. CertificateVerify. A signature over the whole handshake so far, made with the certificate’s private key [2]. This is the proof that the server actually holds that key, and the reason a copied certificate is useless on its own (what a certificate proves).
6. Finished (server). A checksum of every handshake message, made with the new session key so only the two real ends could produce it, so both sides can confirm nobody altered anything on the way [2].
7. Finished (client). The same confirmation from the client’s side, and the client can send its HTTP request right behind it.

The Finished checksums matter because the first two messages aren’t encrypted, so someone in the middle could edit them. Picture an attacker deleting the strongest options from the ClientHello on its way past, hoping the two sides settle on something weaker. The server would answer the edited version, but the client still has the original. Their records of the handshake no longer match, so the server’s CertificateVerify signature and Finished checksum won’t check out on the client’s side, and the handshake fails with a decrypt_error alert instead of quietly carrying on [2].

The whole handshake takes one round trip, a message out and the reply back, before the request can go. If the client guessed wrong about the key exchange method, the server sends a HelloRetryRequest asking for a different one, which costs an extra round trip [2].

Step through it here, and switch to TLS 1.2 to compare:

TLS 1.2: one more round trip

TLS 1.2 is still widely supported, and its handshake takes two round trips instead of one [9]:

• The client’s first message doesn’t include its half of the key exchange, so the key exchange only finishes on the second trip.
• The certificate travels unencrypted, so anyone watching can see exactly which certificate the server sent.
• Older 1.2 setups could use a key exchange without forward secrecy, where stealing the server’s key later would unlock recorded traffic. That’s the main reason 1.3 removed those options [2].

TLS 1.0 and 1.1 are formally deprecated and shouldn’t be used at all [10].

Versions and cipher suites

A cipher suite is the set of algorithms a connection uses. In TLS 1.2, a suite’s name lists everything at once: the key exchange, how the server proves its identity, the encryption, and the hash, which is why 1.2 suite names get long. TLS 1.3 simplified it. Key exchange and signatures are negotiated separately, and the cipher suite only names the encryption and the hash, so there are just five of them, like TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 [2].

Coming back: resumption and 0-RTT

After a full handshake, the server can hand the client a session ticket. Next time, the client presents the ticket and the two sides skip the certificate part, because they’ve already been through it. A resumed handshake still takes one round trip, though. The server proves who it is with the key saved from last time instead of sending its Certificate and CertificateVerify, but the ClientHello still goes out and the ServerHello and Finished still come back before the request can follow [2].

With a ticket, TLS 1.3 also allows 0-RTT (“zero round trip”): the client sends its request alongside its very first message, before the handshake finishes. It’s fast, but it comes with a catch: that early data has no protection against being replayed, so someone who captures it can send it again [2]. It’s only safe for requests where doing the same thing twice is harmless, like loading a page, and never for something like “place an order.”

In a real connection

Where the handshake fits

In the OSI model, TLS sits on top of TCP (layer 4) and underneath HTTP (layer 7), which is why it doesn’t fit neatly into one layer. The TCP connection is set up first, then the TLS handshake runs over it, and only then does HTTP get to speak. So if the handshake fails, the two machines are already connected, but the browser never sends its request and the server never sends the page. One side sends an alert and both close the connection without sending anything else [2]. The one exception is 0-RTT, covered above, where a returning client sends its request before the handshake finishes.

TCP has its own handshake before TLS starts, and the page can’t arrive until the HTTP request has gone out and come back [11], [2]:

Time runs downward. Three round trips pass before the first byte of the page arrives, and everything in teal is encrypted.

Round trips are what make a first connection slow, because each one costs the full travel time to the server and back no matter how small the messages are. If a round trip takes 50 milliseconds, the page starts arriving about 150 milliseconds after the browser starts connecting. TLS 1.2 adds one more round trip, to 200, and a returning client using 0-RTT can save one.

What someone watching can still see

TLS hides the contents of the conversation, but not everything:

• The server name. SNI is in the ClientHello, which goes out before any encryption exists, so anyone on the path can see that you connected to app.example.com (just not which page). Encrypted Client Hello (ECH) fixes this by encrypting the ClientHello with a public key the server publishes in DNS, but it needs support from both the browser and the server [12].
• The name, a second way. Before connecting, the browser looked the name up in DNS, and ordinary DNS isn’t encrypted, so anyone on the path can see that lookup too, unless the browser uses encrypted DNS such as DNS over HTTPS [13].
• IP addresses and ports, from the layers below (the OSI model).
• Sizes and timing of the encrypted traffic.
• In TLS 1.2, the certificate as well, since it isn’t encrypted there.

When the handshake fails

When something goes wrong, the side that notices sends an alert, a short message with a name and number from the TLS standard, and closes the connection [2]. Tools print the alert’s name, though the wording varies between them, and some still say “SSL” or “sslv3” for historical reasons. The common failures:

Without SNI, for example, this site’s server (GitHub Pages) answers with its default *.github.io certificate. Certificates and Trust has more on certificate errors, and badssl.com has deliberately broken sites to try them against:

curl --tls-max 1.1 https://camzabriskie.com/   # an old TLS version
curl https://expired.badssl.com/               # an expired certificate
curl https://wrong.host.badssl.com/            # a certificate for a different name

curl.exe --tls-max 1.1 https://camzabriskie.com/   # an old TLS version
curl.exe https://expired.badssl.com/               # an expired certificate
curl.exe https://wrong.host.badssl.com/            # a certificate for a different name

The first one may not get as far as the server. Recent versions of OpenSSL (3.2 and later) turn TLS 1.0 and 1.1 off by default [14], so a curl built on one refuses on your side and prints an error of its own instead of the server’s protocol_version alert. The curl that ships with macOS gets through and shows tlsv1 alert protocol version.

Going further

Mutual TLS

In normal TLS only the server proves who it is. In mutual TLS (mTLS) the server also asks the client for a certificate, and the client answers with its own Certificate and CertificateVerify messages, proving it holds that certificate’s private key the same way the server did [2]. Load balancers and TLS termination covers how that interacts with load balancers.

Watching it happen

curl -v prints the result of the handshake. This command asks for a page, throws the page away (-o), and keeps only the handshake lines from curl’s report (-v turns the report on, -s hides the progress bar):

curl -sv -o /dev/null https://camzabriskie.com/ 2>&1 \
  | grep -E 'ALPN|SSL connection|Server certificate|subject:|issuer:|verify ok'

curl.exe -sv -o NUL https://camzabriskie.com/ 2>&1 |
  Select-String 'ALPN|SSL connection|Server certificate|subject:|issuer:|verify ok'

On Windows, type curl.exe rather than curl, since in Windows PowerShell 5.1 plain curl is an alias for a different command [15]. For this site, on a Mac, it printed:

* ALPN: curl offers h2,http/1.1
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=camzabriskie.com
*  issuer: C=US; O=Let's Encrypt; CN=YR1
*  SSL certificate verify ok.

That’s ALPN choosing HTTP/2, TLS 1.3 with a ChaCha20 cipher suite (the exact naming varies by TLS library), and the certificate chain checking out. curl still says “SSL” because TLS replaced an older protocol called SSL and the name stuck (more on that). AEAD in the cipher’s name stands for authenticated encryption with associated data: encryption that also detects any tampering, in one step. Every TLS 1.3 cipher works that way [2], [16].

curl only reports how the handshake turned out. To see each message from the walkthrough above as it happens, openssl s_client -connect camzabriskie.com:443 -msg prints every handshake message the client sends and receives, and -trace decodes them in more detail [17].

Both of those show the handshake from the client’s side, after it has decrypted everything. To see it the way someone watching sees it, use Wireshark, a free app that records the packets crossing your network connection and decodes them. Start a capture, load a site, and type tls into the filter bar to show only TLS traffic [18]. The ClientHello is there in full, site name included, and so is the ServerHello, and everything after that shows up only as encrypted data.

References

Every source cited across the primers is collected on one page.