What the Handshake Has to Accomplish
Every TLS handshake has three jobs to finish before any web data flows, and it is worth holding them in mind as the messages go back and forth:
- Agree on the rules — which version of TLS, and which cipher suite (the set of algorithms) both sides will use.
- Authenticate the server — the client must verify, via the server's certificate, that it is really talking to the intended site and not an impostor.
- Establish a shared key — both sides must end up holding the same secret key without ever sending it across the network, so that all later traffic can be encrypted with fast symmetric encryption.
This guide walks the handshake in detail; for the wider context of certificates and trust, the how TLS works overview sets the scene. The handshake itself sits on top of an already-established TCP connection — TLS secures the channel that TCP opens.
The TLS 1.2 Handshake: Two Round Trips
For years the standard flow was the TLS 1.2 handshake, which takes two full round trips between client and server. It is the clearest version to learn because every step is explicit:
- ClientHello — the client opens by listing the TLS versions and cipher suites it supports, and includes a freshly generated random number. This is a menu of "here is everything I can do."
- ServerHello — the server replies choosing one version and one cipher suite from the client's list, and adds its own random number. The terms are now set.
- Certificate — the server sends its certificate chain, proving its identity and providing its public key.
- Key exchange — the two sides use the chosen algorithm (typically ephemeral Diffie-Hellman) to agree on a shared secret. Crucially, the secret itself is never transmitted; each side derives it from the exchanged values.
- Finished — each side sends a Finished message: a hash of the entire handshake so far, encrypted with the new key. Matching hashes prove nothing was tampered with and both truly share the key.
Only after that second round trip can encrypted application data begin. On a distant connection those two round trips are felt — they are pure latency added before the page even starts loading.
The TLS 1.3 Handshake: One Round Trip
TLS 1.3, the current standard, rethought the handshake to cut a full round trip and tighten security at the same time. The key insight: instead of waiting to be told which key-exchange group the server prefers, the client guesses and sends its key-exchange share immediately in the ClientHello.
- ClientHello — the client proposes versions and cipher suites and already includes its key-exchange share for the groups it expects the server to accept.
- ServerHello + everything — because the client's share arrived in message one, the server can immediately reply with its own share, its certificate, and its Finished message — all in a single response. From the point the server sends its share, the rest of the handshake is encrypted.
- Client Finished — the client verifies the certificate, confirms the keys match, and sends its own Finished. Encrypted data can flow from here.
The result is one round trip instead of two. TLS 1.3 also trimmed the cipher-suite menu down to a handful of modern, secure options, removing the legacy choices that caused most past vulnerabilities — so the negotiation is both faster and safer.
0-RTT: Sending Data Before the Handshake Finishes
TLS 1.3 adds one more trick for connections to a server you have visited before. Using a session ticket from the previous visit, the client can send encrypted application data in its very first message — zero round trips of waiting. This 0-RTT mode makes repeat visits feel instant. It comes with a caveat: that earliest data is vulnerable to being replayed by an attacker, so it is reserved for safe, repeatable requests (an idempotent GET, for instance) and never for actions that change state.
Why the Random Numbers and the Finished Message Matter
Two details in the handshake are easy to skip past but do quiet, essential work. The random numbers each side contributes are mixed into the key derivation so that even if the same parties connect twice, they produce different keys each time — this is what stops an attacker from recording one session and reusing its key against another. And the Finished message, by hashing the whole handshake under the new key, retroactively protects every earlier message: if an attacker had altered the ClientHello to strip out strong cipher suites (a downgrade attack), the hashes would not match and the connection would abort. The handshake, in other words, checks its own integrity at the very end. Combined with forward secrecy from the ephemeral key exchange, this is what makes a modern TLS connection resistant even to an adversary who records everything and steals the server's key later.
Frequently Asked Questions
What is the TLS handshake?
The negotiation at the start of an HTTPS connection, before any web data flows. The client and server agree on a version and cipher suite, the server proves its identity with a certificate, and the two establish a shared secret key. Everything after the handshake is encrypted with that key.
How many round trips does a TLS handshake take?
TLS 1.2 needs two round trips before encrypted data can flow. TLS 1.3 cut this to one by having the client send its key-exchange share in the first message, and adds an optional 0-RTT mode for resumed connections where data goes out immediately.
What happens during the ClientHello and ServerHello?
In the ClientHello the client proposes supported versions and cipher suites and sends a random value. In the ServerHello the server picks one version and suite, sends its own random value, and in TLS 1.3 also includes its key share and certificate. These messages set the terms for the rest.
Is the TLS handshake encrypted?
The earliest messages are sent in the clear since no key exists yet. TLS 1.3 encrypts most of the handshake — including the certificate — as soon as the key-exchange parameters are known, leaving only the initial hellos unencrypted. The hostname can still leak unless Encrypted Client Hello is used.
What is the Finished message in TLS?
The last handshake step from each side, containing a hash of the entire handshake so far, encrypted with the new key. Matching hashes prove the handshake was not tampered with and both sides share the same key — so encrypted application data can begin.