# How the TLS handshake works, and what interviewers probe

Source: https://www.techinterview.org/post/3233477262/tls-handshake-interview/
Updated: 2026-08-07 · techinterview.org

Ask a backend candidate what happens after DNS resolves the hostname but before the first HTTP byte leaves the machine, and you learn quickly whether they understand TLS or just know that the padlock means "encrypted." The gap between those two answers is most of what a TLS question is testing.

The setup: a TCP connection is open to port 443, and now the client and server run a handshake that agrees on keys, proves the server's identity, and flips the channel to encrypted. In TLS 1.3 that costs a single round trip. Get the shape of that round trip right and you can answer almost anything an interviewer builds on top of it.

## The TLS 1.3 handshake in one round trip

The client opens with a `ClientHello`. That message already carries a key share: an ephemeral Diffie-Hellman public key (usually X25519), the list of cipher suites the client supports, the protocol version, and the Server Name Indication (SNI) so a server hosting many domains knows which certificate to return. The client is guessing that the server will accept its key share, and almost always the guess is right.

The server answers with a `ServerHello` carrying its own DH key share and the chosen cipher suite. From those two key shares both sides derive the same shared secret, and everything after this point is encrypted. Inside that encryption the server sends its certificate chain, a `CertificateVerify` (a signature over the handshake transcript, proving it holds the private key for the leaf certificate), and a `Finished` message. The client validates the chain, checks that signature, sends its own `Finished`, and starts writing the HTTP request. One round trip, then data.

That single-round-trip design is the headline change from TLS 1.2, which needed two. The quieter change is that 1.3 deleted the parts of 1.2 that kept going wrong: RSA key transport, static Diffie-Hellman, CBC-mode ciphers, renegotiation, TLS-level compression. What survives is a short menu, which is why 1.3 cipher suite strings look stripped down. `TLS_AES_128_GCM_SHA256` names an AEAD cipher and a hash and says nothing about key exchange or the signature algorithm, because those are negotiated on their own now.

| Property | TLS 1.2 | TLS 1.3 |
| --- | --- | --- |
| Round trips before application data (full handshake) | 2 | 1 (0 on resumption) |
| Key exchange | RSA key transport or (EC)DHE | (EC)DHE only; forward secrecy mandatory |
| Bulk cipher modes | RSA, CBC, RC4, GCM, and more | AEAD only (AES-GCM, ChaCha20-Poly1305) |
| Certificate and later handshake messages | Sent in cleartext | Encrypted |
| What the cipher suite name covers | Key exchange + auth + cipher + MAC | Cipher + hash only |
| Removed legacy features | Renegotiation, compression, static keys present | All removed |
| Post-quantum hybrid key exchange (X25519MLKEM768) | Not defined | Supported; default in major browsers since 2024 |

## Why forward secrecy is the answer they are fishing for

A standard follow-up: "An attacker records all your encrypted traffic today and steals the server's private key a year from now. Can they read the recorded traffic?" With TLS 1.3, no. The keys that actually encrypt data come from the ephemeral Diffie-Hellman exchange, and those ephemeral private keys are discarded when the connection closes. The certificate's private key only signs the handshake; it never encrypts data. Stealing it later lets an attacker impersonate the server going forward, but it decrypts nothing that was captured in the past. That property is forward secrecy, and 1.3 makes it non-optional.

TLS 1.2 allowed a mode where the client encrypted the session key under the server's RSA public key and shipped it across. Steal that one RSA key and every recorded session it ever protected falls open at once. Traffic captured in the early 2010s is still sitting in storage somewhere for exactly this reason. Knowing why ephemeral (EC)DHE beat RSA key transport is the line between a candidate who memorized "use 1.3" and one who can say what it buys.

## The certificate chain is where most people get vague

The server sends a leaf certificate for its domain plus one or more intermediate certificates. The client already trusts a set of root CAs baked into the operating system or browser. Validation walks the chain from leaf toward a trusted root: each certificate is signed by the one above it, the names match, none has expired, none is revoked. The leaf's Subject Alternative Name has to cover the exact hostname the client asked for, which is why a certificate issued for `example.com` throws an error on `www.example.com` unless it lists both names.

Two spots invite deeper questions. Revocation, because it is genuinely messy: CRLs are large and go stale, OCSP adds a network round trip and leaks which sites you visit, and OCSP stapling exists to patch that by having the server attach a fresh signed status itself. And self-signed certificates, because explaining why they fail (no path to a trusted root) shows whether the candidate understands what trust means here or treats the padlock as a magic icon.

## Resumption, 0-RTT, and the replay trap

After a first handshake the server can hand the client a session ticket. On the next connection the client presents the ticket and skips the certificate exchange, which is cheaper. TLS 1.3 also allows 0-RTT: the client sends application data in its very first flight, encrypted under a key derived from the earlier session's resumption secret, before the server has said anything at all. Zero round trips to first byte, which is a real latency win.

The catch, and this is the follow-up that trips people, is that 0-RTT data is replayable. An attacker who captured that first flight can send it again, and the server has no fresh handshake context yet to reject the duplicate. So 0-RTT is only safe for idempotent requests. A GET for a static asset, fine. A POST that charges a card, not fine. The strong answer names the replay risk before the interviewer has to.

## mTLS and where it shows up

Ordinary TLS authenticates the server to the client. Mutual TLS makes the client prove its identity too, presenting its own certificate that the server validates against a CA it trusts. You rarely meet this on public websites, but it runs everywhere inside modern infrastructure. Service meshes like Istio and Linkerd issue short-lived certificates to every workload and require mTLS between services, which is how a zero-trust network confirms that service A really is service A and not something that wandered onto the subnet. When a system-design prompt turns to service-to-service authentication, mTLS is usually the clean answer.

## The post-quantum change that entered interviews in 2026

This is the current one, and it catches anyone who last read about TLS a few years back. The X25519 exchange protecting nearly every HTTPS connection is breakable by a large enough quantum computer, and an attacker can record traffic now to decrypt it once such a machine exists. To get ahead of that harvest-now-decrypt-later threat, browsers and servers moved to a hybrid key exchange called X25519MLKEM768. It runs classical X25519 and post-quantum ML-KEM-768 side by side and folds both results into the shared secret, so the connection stays safe as long as either half holds.

Chrome turned it on by default in version 124, the other major browsers followed, OpenSSL 3.5 and Go 1.24 ship it enabled, and Cloudflare upgraded millions of origin-facing connections automatically. By the second quarter of 2026, more than half of the web requests Cloudflare handles use post-quantum key agreement. One practical wrinkle is worth carrying into an interview: ML-KEM keys are large, so the ClientHello now often outgrows the old single-packet size and spreads across multiple TCP segments, which has exposed real bugs in middleboxes and load balancers that assumed a ClientHello always fit in one read. That kind of specific, current detail is what separates a recited answer from someone who actually follows the protocol.

## What the questions actually sound like

Phrased the way they get asked in a real loop:

- "Walk me through everything from the moment TCP connects to port 443 until the first HTTP request goes out."

- "How does TLS 1.3 reach one round trip when 1.2 needed two?"

- "Someone steals the server's private key tomorrow. What past traffic can they read, and why?"

- "How does the browser decide a certificate is valid?"

- "Why is 0-RTT data risky, and when is it fine to send?"

You can watch all of this against any live server. Run `openssl s_client -connect example.com:443 -tls1_3` and it prints the certificate chain, the negotiated cipher, and the protocol version; add `-msg` and the raw handshake messages scroll past as they happen.

The people who do well here do not recite the message names in order. They explain what each step buys. The key share exists so nobody watching the wire learns the encryption keys. The certificate exists so you know who is on the other end. The Finished messages exist so neither side can be lied to about what was negotiated. Anchor the answer to those three jobs and the mechanics hang off them on their own, which is roughly why the question gets asked in the first place.