What Is a TLS Handshake? How HTTPS Proves It's Safe to Talk

Type a URL, hit enter, and within a few hundred milliseconds your browser is exchanging encrypted data with a server it has never met. What makes that safe is a short exchange that runs before any real traffic: the TLS handshake. It negotiates the encryption parameters, generates the session keys, and — crucially — gives the client proof that the server is actually who it claims to be. Get it wrong and every other security guarantee in the stack quietly evaporates.

What problem the handshake solves

The internet doesn't have a built-in notion of "safe to talk to." Three things go wrong if you just send data over the network:

• Eavesdropping. Anyone on the path — an ISP, a café's Wi-Fi, a compromised router — can read plaintext traffic.
• Impersonation. An attacker can stand up a fake server for yoursite.com and intercept what you send.
• Tampering. Even if nobody reads your traffic, a man-in-the-middle can rewrite it in flight.

The handshake is the mechanism that turns a dumb network into a channel that is confidential (only the two ends can read it), authentic (the client knows who the server is), and integrity-protected (any tampering is detectable). Everything after the handshake is encrypted with symmetric keys generated during it.

The handshake, step by step

TLS 1.3 (RFC 8446) is the current version of the protocol, and its handshake is deliberately short — one round trip in the common case. Here is the normal server-authentication flow:

1. ClientHello. The client opens the conversation with a message containing its supported protocol versions, a list of candidate cipher suites, and one or more KeyShare entries — half of a key-exchange computation (typically X25519, Curve25519, or similar). This is the client's first contribution to the shared secret.

2. ServerHello. The server picks a version and cipher suite, and responds with its own KeyShare for an agreed key-exchange group. The moment both sides hold matching KeyShares, each can independently derive the session keys — no further messages needed to encrypt the rest of the handshake itself.

3. Server authentication. The server then sends, in encrypted form: EncryptedExtensions (its chosen parameters), its Certificate (an X.509 certificate issued by a trusted CA, binding its public key to a domain name), a CertificateVerify signature proving it holds the private key behind that certificate, and a Finished message that both sides can use to detect tampering of everything sent so far.

4. Client confirms. The client validates the certificate chain, checks the domain name, verifies the signature, and sends its own Finished. Now both sides have session keys, and both sides know the transcript wasn't altered. Application data can flow.

A notable variant: if the server can't use the client's KeyShare (say, it doesn't support the client's preferred key-exchange group), it replies with a HelloRetryRequest instead of a normal ServerHello, forcing the client to send a fresh ClientHello with an acceptable group. It costs one extra round trip, which is why it's rare on well-tuned servers.

Why the certificate matters

Key exchange gives you a shared secret that even the server can't derive from the wire alone. But a shared secret alone doesn't stop impersonation: an attacker could run their own handshake with you using a different key pair. The certificate is what binds the server's public key to yoursite.com.

Under the hood, that binding is a Public Key Infrastructure (PKI) trust chain: the server's certificate is signed by a certificate authority (CA) whose root certificate your browser or OS trusts, and every step in the chain must verify cryptographically. Your client checks the signature, validity dates, revocation status, and the domain name in the certificate. The browser's padlock is the UI layer on top of this verification — not a signal that the server is safe, just that the identity check passed.

Mutual TLS: when the client proves itself too

In the standard flow, only the server is authenticated. But TLS can require the reverse: the server requests a client certificate, and the handshake won't complete until the client presents one that the server trusts. This is mutual TLS (mTLS), and it's the backbone of API-to-API authentication, device fleets, and zero-trust mesh networks. Instead of sharing an API key, the client proves it by holding a private key whose certificate the server trusts.

What TLS 1.3 actually changed

TLS 1.3 (mandated in 2018) was a cleanup of TLS 1.2. The changes that matter in practice:

• Faster to first byte. The client sends its KeyShare up front in the ClientHello, so the keys are ready by the time the server's flight arrives. One less round trip than TLS 1.2 in the common case.
• 0-RTT. With session resumption, a returning client can send data in its very first flight — at the cost of a replay window that requires careful application design.
• Legacy suites removed. Weak ciphers, static RSA key exchange, and MD5-based MACs are gone. What remains is a small set of AEAD ciphers (AES-GCM, ChaCha20-Poly1305) that provide both confidentiality and integrity.
• A cleaner state machine. Messages are ordered and encrypted earlier, which shrinks the surface area for downgrade and middlebox attacks.

If you're still seeing TLS 1.0 or 1.1 handshakes in your traffic, those clients or servers are running obsolete protocol versions and should be treated as a review item, not a legacy oddity.

How to see a handshake yourself

You don't need a packet capture to inspect what just happened — your browser does it for you. Click the padlock, expand the certificate and connection details, and you'll see the negotiated protocol version, the cipher suite, and the certificate chain your client actually validated. For a full wire-level view, openssl s_client -connect host:443 prints the handshake as it runs; Wireshark decodes the individual ClientHello, ServerHello, and Certificate messages.

Sources: RFC 8446 (The TLS Protocol Version 1.3) and the TLS specification history, plus published TLS protocol guides.