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

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. ```hint 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. ``` #### 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? ```hint 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. ``` #### 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? ```hint 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. ``` #### 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 ### What a Strong Answer Covers - The correct sequence and purpose of each phase, not just a list of message names - A clear separation of authentication (certificates, signatures) from confidentiality (ephemeral key exchange, symmetric encryption) - Accurate differences between TLS 1.2 and TLS 1.3 - Practical consequences: added latency, where TLS terminates, and common failures such as expired certificates or hostname mismatches ### 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?