This question tests whether you know TLS as a concrete message exchange, not as a vague "it encrypts things." The interviewer wants the flight structure and the round-trip ledger — that's what distinguishes people who have read a capture from people who haven't.
The mental model: two phases — key agreement, then encrypted application traffic.
TLS 1.2, still widely deployed, costs two round trips before the first byte of HTTP:
- Client sends ClientHello (protocol version, cipher suites, a random nonce).
- Server replies ServerHello with the chosen suite, its certificate chain, and a key-exchange message. This flight ends RTT 1.
- Client sends its key-exchange contribution plus ChangeCipherSpec and Finished. The server verifies and sends its own Finished. That completes RTT 2.
Total: 2 RTTs on top of TCP's handshake, so a fresh https connection is 3 RTTs before the request goes out. On a 30ms RTT that's ~90ms of pure protocol before your GET.
TLS 1.3 collapses this. The client sends its key-share (an X25519 public key) in the ClientHello; the server can derive the session key immediately and respond with ServerHello, certificate, and Finished in one flight — so the handshake is 1 RTT. With session resumption via pre-shared keys, TLS 1.3 offers 0-RTT: the client encrypts the first request speculatively with a key from a prior session. That's the "0-RTT" you see in benchmarks — and it's why the TLS trace looks almost flat on reused connections.
The key agreement itself: the two sides do ECDHE, so the session key is derived from ephemeral public keys plus the shared secret — forward secrecy means a leaked server private key can't decrypt recorded traffic. The certificate is just the identity binding: the client validates the chain up to a trusted root during RTT 1's server flight; the cryptography that protects the data is the ECDHE key exchange, which never touches the cert's private key.
Tradeoffs and edge cases: 0-RTT costs replay protection — a replayed ClientHello-encrypted request can be replayed by a network attacker, so servers only allow it for idempotent requests. Certificate validation involves OCSP or CRL checks that can add latency unless stapled. And TCP + TLS + HTTP means a cold connection can be 4 RTTs end to end — the whole reason HTTP/3 moved handshakes onto QUIC, merging transport and crypto setup into one round trip.