When you connect to an https:// site, two computers that have never met must agree on a secret encryption key — and they have to do it over a network where anyone can read every packet. This sounds impossible, and it’s the quiet miracle the TLS handshake performs before any real data flows. It solves two problems at once. First, authentication: the server presents a certificate signed by a Certificate Authority your device already trusts, proving it really is who it claims — this is what stops an impostor. Second, key agreement: using ephemeral Diffie-Hellman, client and server each pick a private number, exchange the corresponding public numbers in the clear, and then each combines the other’s public number with their own private one to compute the exact same shared secret — a value that was never sent across the wire. An eavesdropper sees the public numbers but can’t feasibly work backward to the secret. Step through the messages and watch both sides arrive at the identical key.
certificate proves identity · ephemeral Diffie-Hellman derives the same secret · never transmitted
certificate
A server’s identity document, signed by a Certificate Authority your device trusts. Proves the server is who it claims.
Diffie-Hellman
A method where two parties derive a shared secret by exchanging only public numbers — the secret itself is never sent.
ephemeral
Fresh keys per session (the “E” in ECDHE). If a key later leaks, past sessions stay safe — forward secrecy.
forward secrecy
Recording today’s encrypted traffic and stealing the server’s key tomorrow still won’t decrypt it.
handshake.js — same secret, never sent
Ready
Client and server will agree on a secret key while an eavesdropper watches every packet. Press Next ▸ to send each handshake message. Watch the shared secret appear identically on both sides — computed, never transmitted.
a=?
client private
b=?
server private
🔓
shared secret
👁 Eavesdropper sees: nothing yet
How it works
The handshake’s cleverness is that secrecy and identity are solved by two different mechanisms, and it helps to keep them separate. Identity comes from the certificate chain: your device ships with a set of trusted Certificate Authority root keys, the server’s certificate is signed (transitively) by one of them, and the server proves it holds the matching private key — so you know you’re talking to the real site and not an impostor sitting in the middle. Secrecy comes from Diffie-Hellman, which rests on a one-way math trick: given public numbers A = gᵃ mod p and B = gᵇ mod p, computing the shared secret gᵃᵇ mod p is trivial if you know your own private exponent (the client computes Bᵃ, the server computes Aᵇ, and they’re equal), but an eavesdropper who sees only A and B would have to solve the discrete-logarithm problem to recover an exponent — infeasible at real key sizes. Making the DH keys ephemeral (a fresh pair per session, the “E” in ECDHE) adds forward secrecy: even if the server’s long-term private key is stolen later, yesterday’s recorded traffic can’t be decrypted, because the session key was thrown away and never derived from that long-term key.
1
ClientHello
The client sends its supported cipher suites, a random nonce, and its ephemeral Diffie-Hellman public value A = gᵃ mod p. Its private exponent a stays secret on the client.
2
ServerHello + Certificate
The server replies with its chosen cipher, its own DH public value B = gᵇ mod p, and its certificate — signed by a CA the client trusts — proving its identity. The private exponent b never leaves the server.
3
Both derive the same secret
The client computes Bᵃ mod p; the server computes Aᵇ mod p. Both equal gᵃᵇ mod p — the identical shared secret. It was never transmitted; each side built it from the other’s public value and its own private one.
✓
Finished — encrypted traffic
Both switch to symmetric encryption keyed from the shared secret and exchange Finished messages. Real application data now flows encrypted. The eavesdropper saw A and B but cannot compute the secret.
Identity
certificate (CA-signed)
Secrecy
ephemeral Diffie-Hellman
Sent in clear
A and B (public)
Never sent
the shared secret
The code
# Ephemeral Diffie-Hellman (tiny numbers, real math)
p, g = 23, 5 # public parameters, known to all# Client picks a private exponent, sends only the public value
a = 6; A = pow(g, a, p) # A = 8 (sent in the clear)# Server picks its own, sends only its public value + certificate
b = 15; B = pow(g, b, p) # B = 19 (sent in the clear)# Each combines the OTHER's public value with its OWN private one
client_secret = pow(B, a, p) # 19^6 mod 23 = 2
server_secret = pow(A, b, p) # 8^15 mod 23 = 2assert client_secret == server_secret # same secret — never transmitted
Quick check
1. During the handshake, what actually travels across the network in the clear?
The public DH values A = gᵃ mod p and B = gᵇ mod p travel in the clear, along with the certificate. The shared secret gᵃᵇ mod p is computed independently by each side and is never transmitted — that’s the whole point.
2. What does the server’s certificate provide?
The certificate solves authentication, not secrecy. It’s signed by a CA in the client’s trust store, so the client can verify the server really is who it claims — stopping an impostor in the middle. Secrecy is handled separately by the Diffie-Hellman key exchange.
3. Why does using ephemeral (per-session) DH keys give forward secrecy?
With ephemeral keys, each session derives a fresh secret that isn’t stored and isn’t derived from the server’s long-term key. So even if that long-term key is stolen tomorrow, yesterday’s recorded traffic stays unreadable — the ephemeral secret needed to decrypt it no longer exists.
FAQ
What is the TLS handshake?
The negotiation two computers perform before exchanging encrypted data over HTTPS. It does two jobs: it authenticates the server (via a CA-signed certificate proving identity) and establishes a shared secret key (via Diffie-Hellman, where both sides derive the same key from public values without ever sending it). Then both switch to fast symmetric encryption for the actual data.
How can two computers agree on a secret key over an open network?
Through Diffie-Hellman key exchange. Each side picks a private number and computes a public value (A = gᵃ mod p), exchanges the public values in the clear, then combines the other’s public value with its own private number — both arrive at the identical gᵃᵇ mod p. An eavesdropper sees only the public values and would have to solve the discrete-logarithm problem to recover a private exponent, which is infeasible. The secret is agreed but never sent.
What is the difference between TLS 1.2 and TLS 1.3?
TLS 1.3 is a major simplification and speed-up: it cut handshakes from two round-trips to one (1-RTT), removed old weak ciphers, and made forward-secret ephemeral key exchange mandatory. TLS 1.2 allowed non-forward-secret exchange (static RSA) and had more footguns. TLS 1.3 also supports 0-RTT resumption for returning clients, trading a little security for lower latency.
What stops a man-in-the-middle attack during the handshake?
The certificate. Diffie-Hellman alone stops a passive eavesdropper but not an active attacker relaying messages and doing a separate exchange with each side. The defense is authentication: the server signs the handshake with the key matching its certificate, which is CA-signed and in the client’s trust store. An attacker can relay but can’t forge a valid certificate for the real domain, so the client detects the mismatch and aborts. Encryption without authentication isn’t enough.