TLS Handshake Reference
Searchable reference for the TLS 1.2 / 1.3 handshake steps.
Overview
The TLS handshake reference walks through every step of a TLS 1.2 and TLS 1.3 handshake — ClientHello, ServerHello, certificate exchange, key share, Finished, and the optional resumption paths. Each step shows what the client and server send, which extensions matter, and how the step differs between the two versions.
Protocol implementers writing a TLS stack, security engineers reviewing a Wireshark trace, and curious developers trying to understand why TLS 1.3 is faster all benefit from a clear TLS handshake walkthrough. Long-tail keywords covered: TLS 1.3 handshake step by step, difference between TLS 1.2 and 1.3 handshakes, and what is a TLS resumption handshake.
How it works
TLS 1.2 (RFC 5246) uses a four-flight handshake. The client sends ClientHello with its cipher suite list. The server sends ServerHello, Certificate, ServerKeyExchange (for ECDHE), and ServerHelloDone. The client sends ClientKeyExchange, ChangeCipherSpec, and Finished. The server sends ChangeCipherSpec and Finished. Two round trips before any application data flows.
TLS 1.3 (RFC 8446) compressed this to one round trip in the normal case. The ClientHello carries a guess at the server's preferred key share, the server replies with ServerHello plus EncryptedExtensions, Certificate, CertificateVerify, and Finished — all in one flight. The client then sends Finished and may immediately send application data. Resumption with psk_key_exchange_modes can shave it further to 0-RTT, with replay-attack caveats.
Examples
- TLS 1.3 fresh handshake: 1-RTT, 4 messages each way after the initial TCP/TLS open.
- TLS 1.3 resumed handshake with 0-RTT: the client sends application data alongside its very first ClientHello.
- TLS 1.2 with ECDHE: 2-RTT, classic four-flight, with the server signing its ephemeral key share for forward secrecy.
- A failed handshake ending in an Alert (e.g.
certificate_unknown,handshake_failure) instead of Finished.
FAQ
Why does TLS 1.3 only have one cipher suite per ClientHello?
It does not — the client can list many. But TLS 1.3 cipher suites are simpler (just AEAD + hash), and the key exchange and signature are negotiated by separate extensions, so the cipher list is much shorter than under TLS 1.2.
What does CertificateVerify do?
The server signs a transcript of the handshake messages with its private key, proving it owns the certificate it just presented. TLS 1.2 baked this into the key exchange step; TLS 1.3 broke it out as an explicit message.
Are extensions optional?
Most are, but a few are effectively required: server_name (SNI), supported_versions, key_share, and signature_algorithms in TLS 1.3. Without them the handshake fails immediately.
What is the 0-RTT replay risk?
Application data sent in the 0-RTT phase can be captured and replayed by an attacker. Use it only for idempotent requests; servers commonly restrict 0-RTT to GET on safe URLs.