TLS & the Handshake

The natural first move is symmetric encryption: both sides hold the same secret key, and that one key both locks (encrypts) and unlocks (decrypts) the data. Modern symmetric ciphers — AES-GCM, ChaCha20-Poly1305 — are fast (hardware does gigabytes per second) and, as a bonus, they're authenticated: they attach a short integrity tag to the ciphertext, so any tampering is caught on decryption. (These are called AEAD ciphers — you'll see the term in cipher-suite names.) So symmetric encryption actually handles two of our three problems — confidentiality and integrity — cheaply.

There's exactly one snag, and it's the whole ballgame: both sides need the same key first. Alice's browser and bank.com have never met. If Alice picks a key and sends it over the wire, Eve (the eavesdropper) reads it in transit and now holds the key too. You can't send the shared secret over the very channel you're trying to secure. So the real question isn't 'how do we encrypt' — it's 'how do two strangers agree on a shared key while an eavesdropper watches every byte?'

The breakthrough is a key exchange. Each side generates a keypair: a private value it never reveals, and a matching public value it can safely broadcast. (A keypair — one secret half, one shareable half — is the whole idea behind asymmetric cryptography, and we'll use it again in a moment for identity.) The two sides swap their public values. Then a bit of math lets each one combine its own private value with the other's public value and land on the exact same result: a shared secret. An eavesdropper who sees only the two public values can't compute it. The classic construction is called Diffie–Hellman (DH).

The usual intuition is paint mixing. Alice and the server agree on a public starting color. Each stirs in a secret color of their own and sends the mixture across in the open. Each then adds their own secret color again — and both end up with the same final blend. Eve saw the two mixtures go by, but she can't 'un-mix' them to recover either secret color. Separating mixed paint is the hard part, and that one-way difficulty is what keeps the shared secret secret.

That shared secret is exactly what symmetric encryption was missing: the same key, now held by both Alice and the server, without either one ever sending it over the wire. This value — call it the Diffie–Hellman key — is run through a key-derivation step to produce the actual symmetric session keys (the keys the AEAD cipher uses to encrypt this connection's traffic). So the earlier snag — 'both sides need the same key first' — is solved. In real TLS the exchange runs over elliptic curves (ECDHE — Elliptic-Curve Diffie–Hellman Ephemeral), which is faster and needs far smaller keys than the original integer version. Notice what we've achieved: the key was never transmitted, so Eve — who recorded every byte — still doesn't have it. Confidentiality's bootstrap is solved. But a gap remains, and it's the sneaky one.

The gap: Diffie–Hellman gets you a shared secret with whoever is on the other end — but it says nothing about who that is. If Eve intercepts the connection and does her own DH exchange with Alice (pretending to be the bank) and a separate one with the bank (pretending to be Alice), she ends up with two shared secrets, sits in the middle, and reads everything while both sides think they're secure. Key exchange without identity is a man-in-the-middle's paradise. We need authentication.

Authentication reuses that same keypair idea for a second job. The server has its own long-term keypair — separate from the throwaway DH one — keeping the private key secret and publishing the public key. A digital signature works like this. To sign, the server runs a message through a function that mixes in its private key, producing a short signature. To verify, anyone with the matching public key runs a check that passes only if that private key signed that exact message. And forging a signature without the private key isn't feasible: recovering the private key from the public one takes the same infeasible math the key exchange relied on.

So when the server signs part of the handshake and Alice checks it with the public key, a passing check proves exactly one thing: the other end holds the private key that matches this public key. That's real, but not enough on its own. Alice still has no way to know whether this public key belongs to bank.com or to Eve. Tying a public key to a real-world identity is the missing piece.

The answer is a certificate: an X.509 document that binds a public key to a domain name (bank.com), and is itself signed by a Certificate Authority (CA) — a trusted third party whose own public keys ship pre-installed in your operating system and browser (the trust store). Your device trusts a few hundred root CAs out of the box. When the server presents its certificate, Alice checks that a CA she already trusts vouched for it by signing it. Eve can't forge this: she can generate a key pair claiming to be bank.com, but no trusted CA will sign it for her — a CA issues a certificate for a domain only to someone who can prove they control it (we'll see how at Let's Encrypt below) — and a self-signed claim fails the check (that's the scary browser warning).

So how does the certificate actually stop the man-in-the-middle? Walk it through:

1. The certificate is public — Eve can copy bank.com's. But it holds only the public key; the matching private key never leaves the real bank.
2. Proving you own a certificate means signing with its private key. Eve doesn't have it, so she can't.
3. And the server signs the handshake transcript, not a fixed phrase Eve could replay. That transcript includes the DH shares just exchanged, so the signature is welded to this one key exchange.
4. In a man-in-the-middle, Eve runs her own DH with Alice, so Alice's transcript carries Eve's share gᵉ, not the bank's gᵇ. The real bank never signs a transcript containing gᵉ — so any signature Eve can get is over the wrong shares, and Alice's check fails.

Eve can't forge a signature (no private key) and can't reuse a real one (wrong shares), so the handshake aborts before any data flows. Diffie–Hellman gave Alice a secret with whoever answered; the signature proves that whoever is the real bank.

TLS 1.3 fuses key exchange and authentication into a single, fast negotiation. The client is optimistic — it sends its DH key share immediately, guessing the server's parameters — so that by the end of one round trip both sides have keys and the client can already send encrypted application data.

1. ClientHello: the client sends the TLS versions and cipher suites it supports — a cipher suite is one bundle of algorithms the two sides agree to use (a key-exchange method, a symmetric cipher, and a hash) — plus a DH key share for its best-guess parameters. This is the one unencrypted flight.
2. ServerHello: the server picks a cipher suite and sends its own key share. From the two shares, both sides now derive the shared secret and the symmetric session keys — everything after this point is encrypted.
3. Certificate + signature: the server sends its certificate chain and a signature over the handshake transcript, proving it holds the matching private key. (Now encrypted, so eavesdroppers don't even learn which cert you got.)
4. Finished (both sides): each sends a MAC (message authentication code — a short integrity tag keyed by the freshly-derived session key) over the whole transcript. If the transcripts don't match — because someone tampered mid-handshake or tried to downgrade the version — the Finished check fails and the connection aborts.
5. Application data: the client verifies the certificate against its trust store and the signature, then sends real HTTP requests inside the encrypted, authenticated channel.

• Session resumption: after a full handshake, the server hands the client a ticket. On the next connection the client presents it and both sides reuse the earlier secret — skipping the expensive asymmetric work and a round trip.
• 0-RTT (early data): resumption's aggressive mode — the client sends application data in its very first flight, before the handshake finishes. Saves a round trip, but because that data goes out before the fresh handshake's anti-replay protection is in place, an attacker can capture and resend it — so 0-RTT is only safe for idempotent requests like GETs, never a 'transfer money' POST.
• Mutual TLS (mTLS): the client also presents a certificate, so both ends authenticate each other. Overkill for public websites (users don't have certs) but the backbone of zero-trust service meshes (Istio, Linkerd) where every service proves its identity to every other.
• SNI (Server Name Indication): the client names the hostname it wants in the ClientHello, so one server IP can host many TLS sites. Historically sent in plaintext (a privacy leak of which site you're visiting); Encrypted Client Hello (ECH) closes that gap.

The story from 1.2 to 1.3 is: fewer choices, safer defaults, faster. The big mechanical change is the key exchange. Alongside Diffie–Hellman, TLS 1.2 also allowed an older RSA-based method: instead of a DH exchange, the client picks the secret itself and encrypts it with the server's public key so only the server can read it. It works, but it has no forward secrecy — if that long-term key ever leaks, every past session it protected can be decrypted. TLS 1.2's other weak spot was choice: a long menu of cipher suites, some of them weak, which let an attacker force a downgrade to a breakable one. TLS 1.3 removed the RSA key exchange (making ephemeral Diffie–Hellman, and therefore forward secrecy, mandatory), cut the menu down to a small vetted set, encrypted more of the handshake, and shaved the full handshake from two round trips to one.

Mutual TLS isn't a separate version — it's an option in both. Turn on client certificates and both ends authenticate each other instead of just the server, which is why service meshes use it to give every service a verifiable identity.

• HTTPS is literally 'HTTP inside a TLS channel' — same HTTP methods and status codes, now confidential and authenticated. HSTS (HTTP Strict Transport Security) is a header that tells browsers to only ever use HTTPS for a domain, defeating downgrade-to-HTTP attacks.
• Let's Encrypt made TLS free and automatic via the ACME protocol: a script proves you control a domain and gets a 90-day certificate, auto-renewed. Short lifetimes shrink the window a stolen cert is useful and reduce reliance on slow revocation. This is the single biggest reason the web went from ~40% to ~95%+ HTTPS.
• Certificate Transparency (CT): every certificate a CA issues is written to public, append-only logs. Domain owners monitor the logs and can spot a certificate they never requested — turning silent mis-issuance into something detectable.
• QUIC / HTTP-3 builds TLS 1.3 directly into the transport (over UDP), so connection setup and encryption setup happen together in one 1-RTT (or 0-RTT) exchange — one of the reasons HTTP-3 connects faster than HTTP-2-over-TCP-over-TLS.
• Revocation (killing a cert before it expires) remains the messy part: CRLs (big download lists) and OCSP (an online query per cert) both have availability and privacy problems, which is why the industry leans on short-lived certs and OCSP stapling instead.

TLS shows up whenever a design says 'and this connection is secured with HTTPS/mTLS.' Interviewers probe whether you understand what that actually buys and costs. Lead with the three guarantees (confidentiality, integrity, authentication), then explain the handshake as the bootstrap that establishes a shared key with a verified party over an open wire.

• Name the split: asymmetric crypto (DH key exchange + certificate signature) to bootstrap trust and a key, then fast symmetric AEAD for the bulk data. Explaining why both exist is the money answer.
• Mention forward secrecy and why TLS 1.3 makes ephemeral DH mandatory — it's the detail that shows you understand the threat model, not just the mechanics.
• Know the cost: a full TLS 1.3 handshake adds 1 RTT on top of TCP; resumption/0-RTT and edge termination are how you claw that back at scale.
• For service-to-service designs, reach for mTLS and zero-trust: every service presents a certificate, identity is cryptographic, not network-location-based.
• Flag the trust shift: TLS moves trust from the network to the CA system, and a valid certificate proves the domain, not the operator's honesty (phishing sites have valid certs).