Cybersecurity glossary
What is a TLS Handshake?
Learn what a TLS handshake is, how clients and servers authenticate and derive keys, how TLS 1.2 and 1.3 handshakes differ, and which failures cause connection errors.
Definition
A TLS handshake is the initial negotiation in which a client and server agree on protocol parameters, authenticate one or both parties with certificates, establish shared secrets, and derive keys that protect subsequent application data records.
Why the handshake decides connection security
Encrypted records are only as trustworthy as the setup that produced their keys. The TLS handshake is where identity, version, key agreement, and cipher choices are decided—so misconfiguration here creates weak sessions even if AES looks fine on a diagram.
Handshake responsibilities
Parameter negotiation
Agree on supported TLS version and cryptographic options.
Authentication
Validate certificate chains and names (and optional client certs).
Key establishment
Derive shared secrets via ECDHE or other approved agreement.
Transcript confirmation
Finished messages bind both sides to the same negotiation outcome.
Conceptual handshake stages
Open with ClientHello
Client advertises versions, suites/groups, SNI, ALPN, and key shares.
Server responds
ServerHello selects parameters; certificate messages convey identity.
Agree on secrets
Ephemeral key agreement feeds the key schedule.
Authenticate
Signatures and chain validation prove the server (and maybe client).
Finish and protect
Finished messages confirm integrity; application data follows under AEAD keys.
TLS 1.2 vs TLS 1.3 handshake traits
Same job, different default hardening and latency.
| Trait | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Typical full handshake | Often 2-RTT | Typically 1-RTT |
| Legacy options | Many (must disable) | Largely removed |
| Encrypted handshake parts | Limited | More messages encrypted |
| Cipher suite meaning | Full stack of algorithms | Mostly AEAD + hash |
Operational checklist
- Capture handshake failures with actionable alerts (chain, name, version, suite).
- Serve complete intermediate chains to reduce path-building failures.
- Ensure SNI certificates match every public hostname.
- Prefer TLS 1.3 handshakes while keeping hardened 1.2 for needed clients.
- Validate mTLS trust stores and client cert revocation policy if used.
- Watch for middleboxes that break modern handshake extensions.
- Test from multiple client platforms after certificate or cipher changes.
- Keep clocks synchronized—handshake validation depends on certificate validity times.
Handshake debugging tip
When users report “SSL errors,” separate DNS problems, certificate identity problems, and version/cipher mismatches. Packet captures or tools like openssl s_client quickly show which handshake stage failed.
The practical takeaway
The TLS handshake authenticates peers and establishes the keys that protect application data. Make negotiation boringly strict, keep certificates correct, and prefer TLS 1.3’s simpler handshake design.
Related security terms
TLS 1.3
Modern handshake design with fewer round trips and AEAD-only crypto.
TLS 1.2
Widely deployed handshake variant with more negotiable legacy options.
Certificate Chain
Presented during the handshake for path validation.
ECDHE
Ephemeral key agreement commonly used to establish handshake secrets.
Cipher Suite
Algorithms selected (TLS 1.2) or simplified (TLS 1.3) during negotiation.
Frequently asked questions
What is a TLS handshake in simple terms?
It is the setup conversation before encrypted application traffic begins. The peers prove identity where required and agree on keys.
Why do handshakes fail?
Common causes include incomplete certificate chains, hostname mismatches, unsupported versions/ciphers, expired certificates, and middlebox interference.
What is SNI used for in the handshake?
Server Name Indication tells a multi-site server which certificate to present for the hostname the client intends to reach.
Does the handshake encrypt everything?
TLS 1.3 encrypts more handshake messages than earlier versions, but some early ClientHello fields remain visible to the network.
Is mutual TLS part of the handshake?
Yes. When mTLS is enabled, the client also presents and proves possession of a certificate during handshake authentication.
How is a handshake different from record protection?
The handshake establishes keys and authenticity. Record protection uses those keys to encrypt application bytes afterward.
Can handshakes be resumed?
Yes. Session tickets or PSKs can shorten subsequent handshakes, with security properties that depend on the TLS version and configuration.
References
Explore authoritative guidance and frameworks related to tls handshake.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.