The TLS (Transport Layer Security) handshake is the negotiation process that happens before any encrypted data is exchanged between a client and server. It establishes a shared secret, verifies identities, and agrees on cryptographic parameters — all in a fraction of a second.
The TLS handshake is a multi-step protocol exchange that kicks off every secure HTTPS connection. It allows the client and server to agree on which version of TLS to use, which cipher suites to apply, and how to authenticate each other. The result is a set of shared session keys used to symmetrically encrypt all subsequent traffic. Without the handshake, there is no secure channel.
The handshake is the foundation of trust and confidentiality on the internet. It prevents eavesdropping by ensuring data is encrypted, and it prevents man-in-the-middle attacks by verifying the server's identity via a digital certificate signed by a trusted Certificate Authority (CA). Every time you see the padlock icon in a browser, a successful handshake has already occurred. Its correctness is critical — a flawed handshake can expose all data that follows.
First, the client sends a ClientHello message containing supported TLS versions, cipher suites, and a random nonce, plus key share data for key agreement. The server responds with a ServerHello selecting parameters, its own key share, and its digital certificate. Both sides can now independently derive the same session keys using the Diffie-Hellman key exchange — no secret is ever transmitted over the wire. The server immediately sends a Finished message encrypted with the derived key, and the client responds in kind, completing the handshake in just one round trip (1-RTT).
The server's certificate contains its public key and is signed by a CA that the client's OS or browser already trusts. The client validates the certificate chain up to a trusted root CA, checks the domain name matches, and verifies the certificate has not expired or been revoked. In mutual TLS (mTLS), the client also presents a certificate, enabling two-way authentication common in microservices and API security. If any certificate check fails, the handshake is aborted and the connection is refused.
TLS 1.2 requires two round trips (2-RTT) before application data can flow, making it slower than TLS 1.3's default 1-RTT. TLS 1.3 also removed support for weak algorithms like RSA key exchange, MD5, and SHA-1, significantly shrinking the attack surface. TLS 1.3 introduces 0-RTT resumption for returning clients, allowing data to be sent immediately, though this comes with replay-attack risks that must be mitigated at the application layer. Prefer TLS 1.3 and disable TLS 1.2 where your client base allows.
A common mistake is neglecting certificate renewal, causing unexpected handshake failures when a cert expires — automate renewal with tools like Certbot or AWS ACM. Cipher suite misconfiguration can silently downgrade security; always audit your server's supported suites with tools like testssl.sh or SSL Labs. Certificate pinning (hardcoding an expected cert or public key in a client app) adds extra protection against rogue CAs but creates operational risk if the pinned cert changes without updating the client. Always have a key rotation and pinning update strategy before deploying pinning in production.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app