Katkat
Back

Explain How TLS Secures a Connection: Handshake, Certificates and Keys

AppleSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSoftware Engineering Fundamentals

Last updated

Explain in detail how TLS establishes a secure connection and protects the data that follows: the handshake messages and round trips, certificate chain validation, ephemeral key exchange and key derivation, record encryption, forward secrecy, and how TLS 1.3 differs from TLS 1.2.

After a coding exercise, the interviewer moved on to networking fundamentals and asked about TLS in detail: how TLS establishes a secure connection between a client and a server, and how it protects the data that flows afterwards.

Clarifying Questions

  • Should I describe TLS 1.3, TLS 1.2, or the differences between them?
  • Is the scenario a browser connecting to a public website, or service-to-service traffic inside a data center where both sides may present certificates?
  • How deep should I go: message by message, or the purpose of each phase?

Part 1 — The handshake

Walk through the handshake from the client's first message until both sides can send application data. Say what the key messages carry, what each achieves, and how many round trips the handshake costs.

What This Part Should Cover

  • The message sequence and the content of the important messages
  • How both sides arrive at the same secret without ever sending it
  • Round trips, and what TLS 1.3 changed relative to TLS 1.2
  • What the final handshake messages protect against

Part 2 — Authenticating the server

How does the client know it is talking to the real server, and not to an attacker in the middle?

What This Part Should Cover

  • Building and validating the certificate chain up to a trusted root
  • Hostname, validity-period and revocation checks
  • Proof that the server holds the private key, and how that proof is bound to this handshake's key exchange

Part 3 — Protecting the data

After the handshake, how are the bytes on the wire protected? And what can an attacker do with recorded traffic if the server's long-term private key is stolen a year later?

What This Part Should Cover

  • Deriving per-direction traffic keys from the shared secret
  • Authenticated encryption of records, nonces, and protection against replayed or reordered records
  • Forward secrecy, and why the old RSA key-transport exchange lacked it
  • What TLS does not hide

Hints

Hint 1

Where the round trip goes: Compare when the client sends its key-exchange material in each protocol version, and how that affects when encrypted application data can start to flow.

Hint 2

A certificate alone proves nothing: Anyone can copy a server's certificate and replay it. Think about what the server must additionally do during the handshake, and what the client checks in the certificate itself.

Hint 3

Two kinds of keys: Separate the key that proves the server's identity from the keys that encrypt this connection, and ask which of them an attacker would need to read recorded traffic.

Follow-up questions

  • What does resumption with zero round trips gain, and why is early data unsafe for requests that are not idempotent?
  • How is a revoked certificate detected, and what should a client do when the revocation check cannot be completed?
  • How does mutual TLS work, and where would you use it between services in a compute platform?
  • Where should TLS terminate behind a load balancer, and what are the trade-offs of each choice?