How TLS handshake works

The Problem Statement

Interviewer: "When a user opens https://example.com in their browser, what actually happens during the TLS handshake before any page content loads? Walk me through TLS 1.3 specifically, including how the client and server agree on encryption keys without ever transmitting them."

This question tests three things: whether you understand the cryptographic primitives behind secure connections (Diffie-Hellman, certificate chains, key derivation), whether you can explain the 1-RTT handshake flow step by step, and whether you understand the security properties TLS provides (confidentiality, integrity, authentication) and their failure modes.

I find this question separates candidates who have actually debugged TLS issues in production from those who just know "HTTPS is encrypted." The strongest answers cover the mechanics of key exchange, explain why forward secrecy matters, and mention 0-RTT resumption with its replay risk.

What you will walk away with after reading this:

• A clear picture of the 1-RTT handshake flow and why each message exists.
• The intuition for how Diffie-Hellman lets two strangers agree on a shared secret.
• Why forward secrecy is mandatory and what it actually protects against.
• How certificate chains establish trust and what can go wrong.
• The tradeoffs behind 0-RTT resumption and when it is safe to use.
• Common mistakes that trip up even experienced engineers in interviews.

TLS is everywhere. Every HTTPS request, every gRPC call, every database connection in a production system uses some form of TLS. If you have ever seen a "certificate expired" alert at 3 AM, you already know why understanding TLS at the protocol level matters. This article gives you the mental model to reason about TLS from first principles, not just memorize the steps.

Clarifying the Scenario

You: "Before I walk through the handshake, let me confirm scope."

You: "Are we focusing on TLS 1.3 specifically, or should I compare it with TLS 1.2 as well?"

Interviewer: "Start with TLS 1.3. Mention 1.2 differences where relevant."

You: "Got it. And should I go deep on the math behind Diffie-Hellman, or focus more on the protocol flow?"

Interviewer: "I want to understand why both sides end up with the same key without transmitting it. You do not need to prove the math rigorously, but I want the intuition."

You: "Should I also cover TLS termination and where it fits in a typical system architecture, or keep this purely at the protocol level?"

Interviewer: "Keep the focus on the protocol itself. You can mention deployment briefly if it is relevant."

You: "Perfect. I will structure my answer in three parts: the three problems TLS solves, the full 1-RTT handshake flow with key exchange, and then deep dives into certificate verification and 0-RTT resumption."

My Approach

TLS is one of those topics where knowing the overview gets you 60% of the credit, but the remaining 40% comes from understanding why each step exists. Interviewers ask about TLS because it sits at the intersection of cryptography, networking, and system design. If you can explain the handshake clearly, you demonstrate that you understand security at a protocol level rather than just "we use HTTPS."

Here is a quick map of the three security goals and which handshake component delivers each:

I break this into four parts:

1. The three guarantees: What TLS actually provides (confidentiality, integrity, authentication) and why all three are needed.
2. The 1-RTT handshake: The full ClientHello to Finished flow, including how TLS 1.3 cut this from 2 round trips to 1.
3. Diffie-Hellman key exchange: How two parties compute identical session keys without transmitting those keys, and why this gives forward secrecy.
4. Certificate chain and trust: How the client knows it is talking to the real server and not an impersonator.

The core insight is that TLS separates authentication (proving identity via certificates) from encryption (establishing session keys via Diffie-Hellman). The server's private key is never used to encrypt data. It is only used to prove identity. The session keys come from ephemeral Diffie-Hellman, which is why compromising the server's certificate key later cannot decrypt past traffic.

Before diving in: every concept here builds on the previous one. The DH exchange produces the shared secret. The certificate chain proves you are sharing that secret with the right party. 0-RTT uses a previous shared secret to skip the exchange. Keep this dependency chain in mind as you read.

The Architecture

Here is the full TLS 1.3 handshake. The critical difference from TLS 1.2 is that the client sends its key share in the very first message, which eliminates one entire round trip.

Walk through what happens:

1. ClientHello: The browser sends its supported cipher suites (like TLS_AES_256_GCM_SHA384), its ephemeral ECDH public key, and the TLS versions it supports. In TLS 1.3, the client sends its key share speculatively in the first message. This is the key optimization that eliminates the extra round trip.

2. ServerHello: The server picks one cipher suite, generates its own ephemeral ECDH keypair, and sends back its public key. At this point, both sides have enough information to compute the shared secret.

3. Encrypted server flight: The server sends its certificate, a signature proving it holds the private key (CertificateVerify), and a Finished message. All of this is encrypted using the handshake traffic key derived from the shared secret.

4. Client Finished: The client validates the certificate chain, verifies the signature, and sends its own Finished message. Application data can now flow.

Total: one round trip. The client can start sending encrypted application data immediately after sending Finished.

Here is the comparison that makes the latency difference concrete:

For your interview: say "TLS 1.3 is a 1-RTT handshake because the client sends its key share speculatively in ClientHello" and move on to the key exchange.

The Diffie-Hellman Key Exchange

This is the part that makes TLS feel like magic. Both sides compute the same shared secret without ever transmitting it. An eavesdropper who captures every packet still cannot derive the key.

Here is the intuition. Imagine mixing paint colors. You and I each privately pick a color. We both start with the same base color (the curve and base point G). I mix my secret color in and send you the result. You mix your secret color in and send me the result. Now we each take what we received and mix our secret color into it. We both end up with the same three-color mixture, but an observer who saw the two intermediate mixtures cannot figure out the individual secret colors.

Elliptic Curve Diffie-Hellman (ECDHE) works the same way, but with point multiplication on an elliptic curve instead of paint. The "hard problem" is that given A = a * G, computing a from A and G (the Elliptic Curve Discrete Logarithm Problem) is computationally infeasible with current algorithms. X25519 uses Curve25519, which gives 128-bit security (equivalent to a 3072-bit RSA key) with only 32-byte keys.

From the shared secret S, both sides run HKDF (HMAC-based Key Derivation Function) to produce multiple independent keys: one for handshake traffic, one for application traffic, and separate keys for each direction. This means even if one derived key leaks, the others remain safe.

The key derivation schedule in TLS 1.3 produces these specific keys from the shared secret: