← Back to Networking

TLS — Certificate, DH, AES

NetworkingSeniornetworkingsecurity

The Question

How does TLS work? Explain certificates, Diffie-Hellman, and AES.

What a Strong Answer Covers

  • certificate from CA
  • "Diffie-Hellman
  • "AES symmetric
  • "asymmetric for exchange

Senior-Level Answer

TLS (Transport Layer Security) provides authentication, confidentiality, and integrity for network connections. It layers three distinct mechanisms to solve three distinct problems: certificates for authentication, Diffie-Hellman for key exchange, and AES for bulk encryption.

Certificates solve the authentication problem: how do you know you're talking to the real server and not an impersonator? A certificate is a digital document issued by a Certificate Authority (CA) that binds a public key to a domain name. The CA signs the certificate with its own private key. Your browser ships with a trust store of root CA public keys. When the server presents its certificate, the browser verifies the CA's signature, confirms the domain matches, and checks the certificate hasn't expired or been revoked. This chain of trust means you only need to trust a small set of CAs — not every server individually. Certificate transparency logs (CT logs) provide public auditability of all issued certificates, making misissuance detectable.

Diffie-Hellman key exchange solves the key distribution problem: how do two parties establish a shared secret over a channel that attackers can observe? In DH, each side generates an ephemeral key pair. They exchange public keys in plaintext. Through the mathematical structure of DH (or its elliptic curve variant, ECDH), each side can compute the same shared secret — but an eavesdropper who sees only the public values cannot compute it without solving the discrete logarithm problem. Modern TLS uses ephemeral ECDH (ECDHE) so each session uses fresh keys — providing forward secrecy: compromise of the server's long-term private key doesn't decrypt past sessions.

AES solves the bulk encryption problem efficiently. Once the shared secret is established, TLS derives symmetric session keys. AES-GCM (Galois/Counter Mode) is standard in TLS 1.3 — it provides both encryption (confidentiality) and authentication (integrity via a message authentication code) in one pass. AES is used rather than asymmetric cryptography for data because symmetric encryption is orders of magnitude faster.

TLS 1.3 (current standard) streamlines this: 1-RTT handshakes with mandatory ECDHE and AEAD ciphers, removal of weaker options like RSA key exchange (which lacks forward secrecy) and CBC mode ciphers. The full handshake: ClientHello (supported ciphers, DH key share) → ServerHello (chosen cipher, DH key share, certificate) → client verifies certificate, both derive session keys, application data flows.

What Separates a 2/3 from a 3/3

2/3 — Passing but Incomplete

Correctly explains all three components and what problem each solves: certificates for server authentication, DH for key exchange, AES for symmetric encryption. Explains the chain of trust for certificates.

3/3 — Strong Answer

All of the above plus: explains forward secrecy and why ECDHE provides it, describes TLS 1.3 improvements over earlier versions, explains AES-GCM's combined encryption+authentication, and can walk through the full handshake sequence.

Common Mistakes

  • Saying TLS just 'encrypts the connection' without distinguishing authentication (certificates) from key exchange (DH) from encryption (AES) — these solve different problems.
  • Confusing the certificate's role (authentication/identity) with the encryption role (AES/symmetric key) — conflating public key crypto with the certificate.
  • Not knowing what forward secrecy means or why it matters — RSA key exchange lacks it; ECDHE provides it.
  • Describing TLS 1.2 behavior (2-RTT handshake, RSA key exchange still common) without noting TLS 1.3 differences.

Follow-Up Questions

  • What is forward secrecy and why does TLS 1.3 mandate it? — Forward secrecy means past sessions can't be decrypted if long-term keys are compromised later. ECDHE generates ephemeral keys per session, so there's nothing to compromise retroactively.
  • What is certificate pinning and when would you use it? — Hardcoding expected certificate or public key hashes in the client, bypassing CA trust. Used in mobile apps for high-security contexts. Risky — cert rotation becomes a deployment event.
  • How does certificate revocation work and why is it hard? — CRL (lists) and OCSP (real-time check) are the mechanisms. OCSP stapling solves the privacy and availability problems of live OCSP checks.
  • Why is AES used for bulk data instead of RSA? — RSA operations are ~1000x slower than AES. Asymmetric crypto is only used for key exchange and authentication; symmetric AES handles all data encryption.

Related Questions

  • TCP — 3-Way Handshake
  • TCP vs UDP
  • HTTP vs HTTPS
  • WebSockets
  • REST vs gRPC

Can You Explain This Cold?

Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.

Get Graded — Free Assessment
GrindQuestionsAITechnical interview assessment
TermsPrivacyAbout