TLS Handshake
Definition
The TLS handshake is the opening exchange of a TLS connection, in which client and server agree on version and cipher, authenticate the server and derive keys.
The TLS handshake is the set of messages exchanged before any application data is protected. The client's ClientHello lists supported versions, cipher suites, key shares and extensions such as SNI and ALPN. The server picks the parameters, sends its certificate chain and proves it holds the matching private key by signing the handshake transcript. Both sides then derive symmetric traffic keys from the key exchange, and each sends a Finished message containing a MAC over the whole transcript, so any tampering or forced downgrade is detected.
Why it matters
Most HTTPS failures surface here: an expired or mismatched certificate, a missing intermediate, no common protocol version or cipher, or a client that omits SNI. The handshake is also the main latency cost of TLS: a full TLS 1.2 handshake takes two round trips, a full TLS 1.3 handshake takes one, and resumption can reduce it further.
Example
TLS 1.3 full handshake (braces mark encrypted messages):
Client Server
ClientHello (key_share, SNI, ALPN) -->
<-- ServerHello (key_share)
{EncryptedExtensions}
{Certificate}
{CertificateVerify}
{Finished}
{Finished} -->
[Application data] <--> [Application data]
To watch a real handshake and see the negotiated version, cipher and certificate chain:
openssl s_client -connect example.com:443 -servername example.com
Common misconceptions
- "The certificate's key encrypts the traffic." In modern handshakes the certificate key only signs; traffic keys come from an ephemeral key exchange.
- "Every request triggers a handshake." A handshake happens per connection, and HTTP keep-alive, HTTP/2 multiplexing and session resumption avoid most repeats.
- "Handshake failures are always certificate problems." Version or cipher mismatches, missing SNI and interfering middleboxes are just as common.