TL;DR: ClientHello carries an ephemeral key share; ServerHello returns the server's; both derive keys from ECDHE (forward secrecy) and everything after is encrypted. The server sends its Certificate (validated to a trusted root, name checked), CertificateVerify (a signature over the handshake transcript, proving it holds the private key for this connection), and Finished (a MAC over the transcript, detecting tampering or downgrade). The client sends its own Finished, and data flows under AEAD. One round trip; 0-RTT resumption is faster but replayable.
How to approach it
Go message by message, and after each one say what it protects against. That turns a memorised list into security reasoning, which is what the interviewer is grading. End with what TLS does not protect.
A strong answer
Client
Server
Client to Server
1ClientHello + key share
1. ClientHello + key share
Ephemeral public key, supported AEAD suites, signature algorithms, server name (SNI).
| Step | What it does | Protects against |
|---|---|---|
| ClientHello / ServerHello key shares | Ephemeral Diffie-Hellman (usually X25519, increasingly hybrid with ML-KEM) | Eavesdropping; decryption of recorded traffic if long-term keys leak later (forward secrecy) |
| Encrypted handshake after ServerHello | Certificates and extensions travel encrypted | Passive observers learning which certificate was presented |
| Certificate | Chain to a trusted root, name matches the requested host | Connecting to a server that cannot show a valid certificate for this name |
| CertificateVerify | Signature over the transcript hash | An attacker replaying someone else's certificate without the private key; splicing handshakes |
| Finished (both sides) | HMAC over the transcript with handshake keys | Tampering with negotiation, including downgrade to weaker options |
| Record layer | AEAD with traffic keys | Reading or modifying data in transit |
What 1.3 removed. RSA key transport (no forward secrecy), static DH, CBC-mode and other non-AEAD ciphers, compression and renegotiation. Fewer options means fewer downgrade paths.
Resumption and 0-RTT. A returning client can use a pre-shared key and send early data in its first flight. Early data is not protected against replay, so servers should accept it only for idempotent requests.
What TLS does not do. It does not protect the endpoints or data at rest, does not decide authorization, and exposes metadata (IP addresses, sizes, timing, and the server name unless Encrypted Client Hello is used). And it provides no authentication at all if the client skips certificate validation.
What interviewers probe next
- "What if the client and server don't share a key-exchange group?" The server sends a HelloRetryRequest naming one it supports, costing an extra round trip.
- "How does mutual TLS differ?" The server sends a CertificateRequest, and the client returns its own Certificate and CertificateVerify, giving the server a cryptographic client identity.
- "Where does TLS commonly fail in practice?" Disabled verification in clients, missing hostname checks, expired certificates, and trusting overly broad internal roots.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A browser connects to https://shop.example using TLS 1.3, and an interviewer asks you to walk the handshake and then defend it as conditions change.
Start here
What happens in the first flight?
When does encryption start in TLS 1.3?
The ClientHello carries supported versions and cipher suites and an ephemeral key share; the ServerHello returns the server's key share. Both derive keys from ECDHE, and everything after is encrypted.
Carry it forwardKey shares in the hellos, encryption right after.
Weak answerDescribing the TLS 1.2 flow.
Constraint changes
How does the server prove its identity?
What proves the server holds the private key?
It sends its Certificate, which the client validates to a trusted root and checks against the hostname, then CertificateVerify, a signature over the handshake transcript proving it holds the private key for this connection.
Carry it forwardCertificate plus CertificateVerify authenticate the server.
Weak answerThinking the certificate alone proves identity.
Constraint changes
What does Finished do?
How would tampering with the hellos be noticed?
It is a MAC over the transcript with keys from the handshake, so any tampering with earlier messages, such as a downgrade attempt, is detected by both sides.
Carry it forwardFinished detects transcript tampering.
Weak answerSkipping Finished in explanations.
Constraint changes
What if the server's private key is stolen next year?
Can past sessions be decrypted?
Recorded sessions stay safe because ECDHE gives forward secrecy: session keys came from ephemeral secrets that were discarded. The attacker can impersonate the server going forward until the certificate is revoked and replaced.
Carry it forwardEphemeral keys protect past sessions.
Weak answerSaying all recorded traffic is now exposed.
Constraint changes
What if a corporate proxy intercepts the connection?
Which root does the browser trust on that device?
It terminates TLS using a certificate from a CA the managed device trusts, then opens its own connection to the site. The browser sees a valid chain to the corporate CA, so the protection depends on that CA and proxy being secure.
Carry it forwardInterception works only through trusted roots.
Weak answerThinking TLS 1.3 prevents all interception.
Now defend it
How would you summarise the handshake and its defences?
Hellos exchange ephemeral key shares for ECDHE; the server's Certificate chains to a trusted root and matches the host; CertificateVerify signs the transcript; Finished MACs it against tampering; forward secrecy protects past sessions after key theft; and interception requires a root the client trusts.
How it's scored
Weak: Lists messages from TLS 1.2 (ServerKeyExchange, ChangeCipherSpec) or says data is encrypted with the server's public key.
Hire: Describes the 1-RTT flow, ECDHE and forward secrecy, and the role of the certificate.
Strong Hire: Explains CertificateVerify and Finished precisely, covers 0-RTT replay, and states what TLS does not protect.
Common mistakes
- Treating the certificate itself as proof of identity, without the private-key proof.
- Forgetting the hostname check.
- Claiming TLS hides which site you visit.
- Accepting 0-RTT for state-changing requests.