TLS Handshake
The TLS handshake authenticates peers and negotiates keys and ciphers, establishing the encrypted channel every HTTPS connection needs.
Definition
The TLS handshake is the sequence of messages that begins a secure connection: the client and server agree on a protocol version and cipher suite, the server proves its identity with a certificate, and both derive shared session keys without transmitting them. TLS 1.3 reduced this to one round trip for a new connection and zero for a resumed one, and removed weak legacy ciphers. The handshake is pure overhead on latency, which is why connection reuse and resumption matter so much.
Context and scope
Every HTTPS, mTLS, and secure-socket connection performs one, so its cost and configuration shape both security and page performance.
Common misconceptions
- The handshake encrypts the request — it establishes keys; encryption of application data happens afterward
- Certificates validate the content — they prove the server identity for a hostname, not the trustworthiness of what it serves
- TLS 1.2 and 1.3 are interchangeable — 1.3 shortens the handshake and drops obsolete primitives; staying on old versions costs both security and speed
Anti-patterns
- Disabling certificate verification anywhere to proceed, removing authentication entirely
- Keeping long certificate chains that add round trips to every new connection
- Relying on obsolete cipher suites or protocol versions for compatibility with untrusted clients
Related concepts
Authoritative source
What it is
The TLS handshake sets up a secure channel. The client offers supported versions, cipher suites, and key material; the server selects a mutually supported set, presents its certificate chain, and proves possession of the corresponding private key; both sides then derive session keys using a key exchange such as ECDHE. TLS 1.3 compresses this into a single round trip and supports resumption, where a prior session secret lets a returning client skip much of the work.
Why it matters
The handshake is where authentication, confidentiality, and forward secrecy are established, and also where latency hides: every new connection pays at least one extra round trip before any application byte flows. Misconfigured handshakes leak trust — accepting any certificate, allowing obsolete ciphers, or letting certificates expire cause outages or compromise. Getting the handshake both secure and short is central to HTTPS performance and safety.
How to use it well
Prefer TLS 1.3 and modern cipher suites, keep certificate chains short, and keep certificates auto-renewed with monitoring before expiry. Enable session resumption and connection reuse so repeat visitors skip full handshakes, and never disable verification. For internal services, combine TLS with client certificates (mTLS) so both ends are authenticated, and automate certificate rotation so expiry never becomes an incident.