TLS & PKI
The padlock, explained: how strangers agree on a secret and how you know you’re really talking to your bank.
What TLS Guarantees
TLS wraps any TCP connection in three guarantees: confidentiality (encrypted, eavesdroppers see noise), integrity (tampering detected), authentication (you verify the server’s identity). HTTPS is just HTTP inside TLS — but TLS also secures SMTP, database connections, gRPC, anything.
Certificates & the Chain of Trust
A certificate binds a public key to an identity (a domain), signed by a Certificate Authority. Your OS/browser ships with ~150 trusted root CAs. Roots sign intermediates; intermediates sign your server’s cert. Verification walks this chain from your leaf up to a root the client already trusts.
The client checks each link: valid signature, not expired, not revoked, and the leaf’s name matches the site (SNI/SAN). Any broken link → the browser’s scary warning. Let’s Encrypt made this free and automated (ACME), which is why HTTPS is now near-universal.
The 1-RTT Handshake (TLS 1.3)
The handshake agrees on a symmetric key and authenticates the server, in one round-trip:
| Step | What happens |
|---|---|
| ClientHello | Client offers cipher suites + its ephemeral DH key share |
| ServerHello | Server picks a suite, sends its key share + certificate chain |
| Key derived | Both sides compute the same shared secret (ECDHE) — never sent on the wire |
| Finished | Encrypted from here; client verifies the cert chain and that the server owns the key |
How TLS Actually Gets Broken
Rarely the crypto — usually the edges: expired or misconfigured certs (self-signed, wrong name), downgrade attacks (tricking a client to an old protocol — mitigated by TLS 1.3 + HSTS), compromised or mis-issued certs (a CA tricked into issuing for a domain — mitigated by Certificate Transparency logs), and the human clicking through the warning. HSTS tells browsers “only ever reach me over HTTPS”, killing the initial-request downgrade window.
Interview Questions
What three things does TLS give you, and which fails silently?
Confidentiality, integrity, authentication. Authentication is the one users defeat themselves by clicking through warnings — the crypto held, the human overrode it. That’s why HSTS removes the “proceed anyway” button.
Explain the chain of trust.
Your browser trusts ~150 root CAs out of the box. A root signs an intermediate, which signs the server leaf. Verification walks leaf → intermediate → root, checking signatures, validity dates, revocation, and name match. Trust a root, transitively trust everything it signed.
What is forward secrecy and how does TLS get it?
Each session derives a unique key via ephemeral Diffie-Hellman (ECDHE) and discards it afterward. A later compromise of the server’s long-term private key can’t decrypt past sessions, because that key was only used to authenticate, not to derive session secrets.
A user sees a certificate warning — what could cause it?
Expired cert, name mismatch (cert for www vs apex), self-signed or untrusted issuer, incomplete chain (missing intermediate), revoked cert, or clock skew on the client. Rarely an actual attack — but indistinguishable from one, which is the point.