What Happens During a TLS Handshake?
Learn what happens during a TLS handshake — certificate verification, key exchange, and TLS 1.3’s 1-RTT speedup.
Expected Interview Answer
A TLS handshake is the process by which a client and server agree on cryptographic parameters, verify the server’s identity via its certificate, and derive a shared symmetric session key — all before any application data is exchanged — so that the connection that follows is both authenticated and encrypted.
In TLS 1.3, the client sends a ClientHello listing supported cipher suites and a key share for key exchange; the server responds with a ServerHello containing its chosen cipher suite and its own key share, plus its certificate and a signature proving it holds the private key matching that certificate. Both sides independently compute the same shared secret from the exchanged key shares using elliptic-curve Diffie-Hellman, without that secret ever traveling over the wire, and derive symmetric session keys from it. The client verifies the certificate chain up to a trusted root certificate authority to confirm it is really talking to the intended server, not an impostor. TLS 1.3 compresses this into a single round trip (1-RTT) before encrypted application data can flow, down from TLS 1.2’s two round trips, and a resumed session using a pre-shared key from a prior handshake can send encrypted data on the very first flight (0-RTT), at the cost of that early data being replayable and thus unsuitable for non-idempotent operations.
- Authenticates the server’s identity via its certificate chain, preventing impersonation
- Derives a shared symmetric key without ever transmitting it, via Diffie-Hellman key exchange
- TLS 1.3 reduces handshake latency to 1-RTT, and 0-RTT for resumed sessions
- Everything after the handshake is encrypted and integrity-protected
AI Mentor Explanation
A TLS handshake is like two team captains meeting at the toss: each shows credentials proving who they actually are — no impostor captains allowed — and they agree on a private hand-signal system for the match that no one watching in the stands can decode. Both captains derive the same secret signal scheme independently, without ever shouting it out loud where opponents could hear. Once that toss ritual finishes, all further communication uses the private, verified signal system. That verify-identity-then-derive-a-shared-secret-without-broadcasting-it process is exactly what a TLS handshake accomplishes before real data flows.
Step-by-Step Explanation
Step 1
Client sends ClientHello
The client proposes supported cipher suites and sends a key share for key exchange.
Step 2
Server responds with ServerHello and certificate
The server picks a cipher suite, sends its own key share, its certificate, and a signature proving key ownership.
Step 3
Both sides derive the shared secret
Using Diffie-Hellman key exchange, client and server independently compute the same symmetric session key.
Step 4
Client verifies and encrypted data begins
The client validates the certificate chain to a trusted root, then application data flows encrypted with the derived key.
What Interviewer Expects
- Clear explanation of what the handshake achieves: authentication plus key agreement
- Understanding of Diffie-Hellman key exchange and why the secret is never sent directly
- Awareness of certificate chain validation up to a trusted root CA
- Knowledge of TLS 1.3’s 1-RTT (and 0-RTT resumption) improvement over TLS 1.2
Common Mistakes
- Confusing symmetric session keys with the asymmetric keys used only during the handshake itself
- Assuming the private key is ever transmitted (only signatures and public certificates travel)
- Not knowing 0-RTT data can be replayed and should never carry non-idempotent operations
- Conflating TLS with the HTTP layer, rather than understanding it sits underneath HTTP as a transport security layer
Best Answer (HR Friendly)
“A TLS handshake is the introduction step before a secure website connection starts. The browser and server prove who they are using certificates, and together they work out a secret key to scramble everything they send afterward — all without ever actually sending that secret key across the network where someone could intercept it.”
Code Example
const tls = require('node:tls')
const socket = tls.connect({ host: 'example.com', port: 443 }, () => {
console.log('Protocol:', socket.getProtocol()) // e.g. 'TLSv1.3'
console.log('Cipher:', socket.getCipher()) // negotiated cipher suite
console.log('Authorized:', socket.authorized) // certificate chain validated
socket.end()
})Follow-up Questions
- Why is elliptic-curve Diffie-Hellman used instead of just encrypting the key with the server’s public key directly?
- What are the security tradeoffs of using 0-RTT session resumption?
- How does certificate chain validation work up to a root certificate authority?
- What is the difference between TLS and mTLS (mutual TLS)?
MCQ Practice
1. What is the primary purpose of the TLS handshake?
The handshake verifies identity via certificates and establishes a shared secret used to encrypt subsequent traffic.
2. How many round trips does a new TLS 1.3 handshake typically require before encrypted application data can flow?
TLS 1.3 reduced the standard handshake to a single round trip; 0-RTT is only available for session resumption.
3. Why is 0-RTT early data considered risky for non-idempotent requests?
Because 0-RTT data is sent before the handshake fully completes, an attacker who captures it can resend it, making it unsafe for actions like payments.
Flash Cards
What does a TLS handshake establish? — Server authentication and a shared symmetric session key, before any application data flows.
How is the shared key derived? — Via Diffie-Hellman key exchange, computed independently by both sides without transmitting the key.
How fast is TLS 1.3’s handshake? — 1-RTT for a new connection, 0-RTT for a resumed session (with replay risk).
How is the server’s identity verified? — By validating its certificate chain up to a trusted root certificate authority.