TLS Handshake Explained: Symmetric and Asymmetric Keys

Introduction

Every time you visit a website over HTTPS, your browser and the server silently execute a cryptographic ritual before a single byte of your data moves. In 2024, Cloudflare reported that over 95% of all web traffic is encrypted with TLS — yet a single misconfigured TLS handshake can expose your users’ credentials, session tokens, and private data to anyone with network access. The 2014 POODLE attack and the 2015 FREAK attack both exploited weaknesses in the handshake negotiation itself, not the encryption algorithms. Understanding how the TLS handshake works is not an academic exercise; it is the foundation of every security review, penetration test, and compliance audit.

The TLS handshake is the negotiation phase that happens before any application data flows. It serves three purposes: it lets the client and server agree on which cryptographic algorithms to use, it authenticates the server’s identity, and it generates the shared secret key that will encrypt the rest of the conversation. TLS 1.3, defined in RFC 8446, redesigned this process to complete in a single round trip — half the round trips required by TLS 1.2 — while simultaneously closing the attack vectors that had plagued its predecessor for a decade.

This article explains what happens at each step of the TLS 1.3 handshake, why it uses two fundamentally different types of encryption, and what the key design choices mean for your security posture. Whether you are a developer debugging a certificate error, a security engineer evaluating your cipher suite configuration, or a compliance professional assessing your organization’s encryption at rest vs in transit controls, this breakdown will give you a clear mental model.

What Is the TLS Handshake?

The TLS handshake is a multi-step protocol that runs over TCP before any HTTP data is exchanged. Think of it as the moment two strangers check each other’s credentials and agree on a secret language before speaking. The handshake accomplishes authentication, algorithm negotiation, and key establishment in a single, tightly orchestrated sequence.

TLS stands for Transport Layer Security — a cryptographic protocol that provides confidentiality, data integrity, and authentication for network communications. It is the successor to SSL (Secure Sockets Layer), which was deprecated in 2015 due to critical vulnerabilities. Every modern HTTPS connection uses TLS, and the handshake is the engine that makes that security possible. You can review the protocol improvements in our TLS 1.3 vs TLS 1.2 comparison.

The handshake operates in the protocol layer between TCP (which handles transport) and the application layer (which handles HTTP). Once the handshake completes, TLS hands off to the Record Protocol, which encrypts and frames every subsequent data packet.

How the TLS Handshake Works

The TLS 1.3 handshake completes in exactly one round trip (1-RTT) under normal conditions. Here is what happens at each step, in plain English.

Step 1: ClientHello. Your browser sends the first message, called the ClientHello. This message contains the list of cipher suites the client supports, the TLS version, a random number (called a client nonce), and — critically — the client’s key share. A key share is the client’s public contribution to an ephemeral Diffie-Hellman key exchange. TLS 1.3 requires the client to speculatively send this key share upfront, without waiting for the server to confirm which group it prefers. This speculation is what collapses two round trips into one.

Step 2: ServerHello. The server responds with its own ServerHello, which includes its chosen cipher suite, its own random nonce, and its key share — the server’s public contribution to the Diffie-Hellman exchange. At this point, both sides have everything they need to independently compute the same shared secret. Neither side ever transmits the shared secret itself; they each derive it from their own private key and the other party’s public key share. This is the mathematical magic of the Diffie-Hellman key exchange.

Step 3: Deriving handshake traffic keys. Using the shared secret and both random nonces, the client and server run a Key Derivation Function (KDF) — specifically HKDF — to derive a set of handshake traffic keys. All subsequent handshake messages are encrypted with these keys. In TLS 1.3, this means the server’s certificate is never sent in the clear. In TLS 1.2, certificates traveled unencrypted, leaking organizational information to passive observers.

Step 4: Server authentication. The server sends its digital certificate, encrypted under the handshake traffic keys. The client verifies that the certificate was signed by a trusted Certificate Authority (CA), that the domain name matches, and that the certificate has not expired. This step is how your browser knows it is talking to the real bank.com and not an impostor. The verification chain relies on public key vs private key cryptography — the CA’s signature on the certificate proves the server controls the private key corresponding to the public key in the certificate.

Step 5: Finished messages. Both parties send a Finished message — a cryptographic hash of the entire handshake transcript — to prove that the handshake was not tampered with. If an attacker inserted or modified any message, the hashes would not match and the handshake would abort.

Step 6: Application traffic keys. After the Finished messages, both sides derive a final set of session keys (application traffic keys) from the shared secret. All HTTP data now flows encrypted with these symmetric keys. The asymmetric key exchange is over; fast symmetric encryption takes the wheel.

VIDEO · READY 16:9

PLAY

TLS Handshake Explained - Computerphile

TLS 1.3 Handshake vs TLS 1.2 Handshake

The table below compares the two handshake designs across the dimensions that matter for security and performance.

The most significant difference is the removal of static RSA key exchange. In TLS 1.2, a server could use its long-term RSA private key to decrypt the session key sent by the client. If an attacker recorded traffic and later obtained that private key — through a breach, a subpoena, or a legal order — they could decrypt every past session. TLS 1.3’s mandatory ECDHE eliminates this retroactive decryption threat.

Real-World Use Cases

API gateway mTLS configuration. When a microservice calls another microservice through an API gateway, the TLS handshake is the first line of defence. DevSecOps teams configure minimum TLS 1.3 and reject connections that fall back to TLS 1.2. Understanding the handshake lets you interpret gateway logs: a “handshake timeout” often means a misconfigured client that cannot find a common cipher suite, not a network problem.

Certificate pinning in mobile apps. Mobile applications sometimes bypass the system’s CA store and compare the server’s certificate fingerprint against a hardcoded value during the handshake. If the fingerprint changes — even because of a legitimate CA rotation — the handshake fails. Security teams audit pinning implementations precisely because a bad pin can brick an app, while no pin at all exposes users to man-in-the-middle attacks on rogue Wi-Fi networks.

Compliance audits for PCI DSS and NIST. PCI DSS v4.0 and NIST SP 800-52 Rev. 2 both mandate TLS 1.2 as a minimum, with TLS 1.3 required for new implementations. Auditors examine cipher suite configurations, certificate validity periods, and whether forward secrecy is enabled. Our PCI DSS compliance overview covers how these TLS requirements fit into the broader cardholder data environment controls.

Common Mistakes to Avoid

Allowing TLS 1.0 or TLS 1.1 as a fallback. These versions support cipher suites that are now broken. Leaving them enabled “for compatibility” means an active attacker can force a downgrade and exploit the weaker negotiated parameters. NIST explicitly prohibits TLS 1.0 and 1.1 for federal systems, and browsers have deprecated them.

Ignoring 0-RTT replay risk. TLS 1.3’s 0-RTT resumption lets returning clients send application data before the handshake completes, using a pre-shared key from a previous session. This is faster but carries replay risk: a network attacker can re-send the 0-RTT data to the server. Applications that accept 0-RTT data must treat it as potentially replayed and reject non-idempotent operations (like payments).

Misconfiguring the cipher suite list. Not all TLS 1.3-compatible cipher suites are equally strong. The OWASP TLS Cheat Sheet recommends allowing only AES-128-GCM-SHA256, AES-256-GCM-SHA384, and ChaCha20-Poly1305-SHA256. Leaving CBC-mode cipher suites in the TLS 1.2 fallback list exposes servers to BEAST and LUCKY13 attacks. If you don’t know how to read these strings, see What Is a Cipher Suite for a breakdown of the naming convention. Our article on ChaCha20-Poly1305 explains why the stream cipher option is particularly valuable for mobile clients.

Letting certificates expire. An expired certificate causes an immediate handshake failure — the client’s chain-of-trust verification step will reject it. Automated certificate management (ACME protocol, used by Let’s Encrypt) eliminates this risk for public-facing services. For internal PKI, use short-lived certificates (90 days or fewer) and automate renewal.

Not monitoring certificate transparency logs. If a rogue CA issues a certificate for your domain, the only way to detect it is via Certificate Transparency (CT) logs. Every public CA is now required to submit certificates to CT logs, and monitoring tools alert you when unexpected certificates appear. Learn more about how CT logs protect your TLS infrastructure in our certificate transparency explainer.

Getting Started

Audit your current TLS configuration first. Use the SSL Labs Server Test (ssllabs.com/ssltest) to scan your public-facing servers. The report tells you which TLS versions are accepted, which cipher suites are offered, whether forward secrecy is enabled, and how your configuration compares to NIST and PCI DSS requirements. Fix any “F” or “C” ratings before doing anything else.

Enforce TLS 1.3 as the minimum for new services. Modern load balancers (AWS ALB, NGINX, HAProxy) and CDNs support TLS 1.3 natively. Set TLS 1.3 as the minimum for greenfield services and document any exceptions where TLS 1.2 is required for legacy client compatibility. Every exception is a future liability.

Implement certificate automation. Manual certificate management fails at scale. Whether you use Wildcard or SAN certificates with ACME for public certs or an internal CA for private services, automate issuance and renewal. Set expiry monitoring alerts at 30 days and 7 days. A single expired certificate during peak traffic is a self-inflicted outage.

Validate your understanding of the difference between hashing and encryption as the conceptual backbone before configuring cipher suites. The handshake makes no sense without understanding why both types of encryption are needed. Once you have that foundation, the OWASP TLS Cheat Sheet provides the definitive cipher suite priority list for your web server software.

For a broader context on how TLS fits into your encryption strategy — including where it sits relative to application-layer encryption — see our guide on encryption at rest vs in transit.