The TLS handshake: what each step actually does

The TLS handshake is the negotiation at the start of every TLS connection, before your request is sent. Two sides that have never met agree on terms, one of them proves it owns the name being asked for, and both end up holding keys that nobody watching the exchange can reconstruct.

What has to be settled, and why in this order

Every step exists because the next one cannot happen without it.

Nothing can be encrypted until both sides agree which algorithms to use, so the opening messages travel in the clear. Nobody should trust a key from a party whose identity is unproven, so identity is established before the keys are used for anything that matters. And no application data can move until both sides have confirmed they derived the same keys, because a silent mismatch would produce garbage rather than an error.

That ordering also explains why early failures look different from late ones: the early ones are about what the two sides have in common, the later ones about whether one of them is who it claims to be.

Step by step in TLS 1.3

The current version, TLS 1.3, completes a full handshake in one round trip:

1. ClientHello. The client lists the versions and cipher suites it supports, the name it wants in the SNI extension, and a key share for the exchange it expects the server to pick.

2. ServerHello. The server picks a version and a cipher suite and sends its own key share. From here both sides can compute the same handshake keys, and everything after this message is encrypted.

3. EncryptedExtensions. Further settings the server agreed to, such as the application protocol negotiated by ALPN.

4. Certificate and CertificateVerify. The server's certificate chain, then a signature over the handshake so far made with the certificate's private key.

5. Finished, from the server. A value computed over the whole exchange with the derived keys.

6. Finished, from the client. The same check in the other direction. The client can send its first request right after it.

In TLS 1.2 the same work takes two round trips: the server's certificate and key exchange travel unencrypted, and keys are settled in separate ClientKeyExchange and ChangeCipherSpec messages before either side sends Finished.

The client opens with what it can do

The ClientHello is a statement of capability, not a request for anything in particular. It says which protocol versions the client supports, which combinations of algorithms it accepts, and which name it is trying to reach. That last detail matters more than its size suggests: one address commonly serves many names, and without the name up front a server could not know which certificate to present.

The client also sends key exchange material immediately, guessing which method the server will pick. That guess is what lets TLS 1.3 finish in fewer round trips than TLS 1.2.

The server answers with what it chose

The ServerHello is a set of decisions, not a negotiation. It names the version and the cipher suite the server selected and contributes its own key share. From that point both sides derive the same secrets independently: the keys are computed on each side rather than sent between them, so recording the conversation gives an observer nothing to decrypt with. That is also why a stolen server key does not expose past sessions, the property described on forward secrecy.

If the server finds nothing acceptable in what the client offered, the exchange stops here. That failure has nothing to do with certificates and produces no warning about identity, which is why a handshake failure reads so differently from the certificate errors people expect.

The server proves the name is its own

Two separate things happen here, and they are routinely conflated.

• The certificate is presented. It states which names it covers, who issued it and for how long it is valid. What a certificate contains belongs to certificates.

• The server proves it holds the matching private key. This is the CertificateVerify signature, and it is what makes the certificate mean anything. A certificate is public and can be copied by anybody who has seen it; what cannot be copied is a signature only the holder of the private key can make.

Without the second half, the first would prove nothing: somebody could present the certificate of any site they had ever visited. The client then checks the chain, the names and the dates, and stops with a browser warning if any check fails.

Both sides confirm they agree

The exchange ends with each side's Finished message: a value computed over everything said so far, using the derived keys. If the other side computes a different value, the connection is abandoned.

This does two jobs at once. It confirms that key derivation matched, and it detects tampering with the earlier messages, because altered messages produce a different value. That is the defence against an attacker in the path forcing both sides onto weaker terms than they actually support.

How to watch a handshake

Both curl and OpenSSL print the handshake as it happens:

$ curl -v https://example.com/ -o /dev/null
$ openssl s_client -connect example.com:443 -servername example.com -msg

In curl's output, the lines marked TLS handshake show the ClientHello and ServerHello and the negotiated version and cipher. OpenSSL with -msg prints every handshake message by name, which is the quickest way to see where an exchange stops.

Where TLS 1.2 and TLS 1.3 differ

Two differences matter in practice. Latency: TLS 1.3 overlaps agreement and key establishment, so a connection becomes usable one round trip sooner, which matters most for visitors far from the server. And subtraction: TLS 1.3 removed key exchange and cipher options instead of adding them, so a modern handshake has fewer ways to end up in a weak configuration. Which versions to enable is covered on TLS versions.

FAQ