Networking Interview: How Does the TLS 1.3 Handshake Work, and When Is 0-RTT Safe?

Question and Scope

A global API uses TLS 1.3. Walk through a full handshake and a resumed handshake. Explain what is encrypted at each stage, how the certificate authenticates the server, how the keys are produced, and whether GET /rates and POST /transfers should use 0-RTT.

Use an explicit baseline: the client connects to an HTTPS service over TCP; the server authenticates with an X.509 certificate; a full handshake uses ephemeral ECDHE; a resumed connection uses a session ticket issued on an earlier connection; and the API entry point may be a load balancer or CDN. HTTP/3 integrates TLS 1.3 into QUIC connection establishment, but the baseline uses TLS records over TCP to make message order and security properties concrete.

This question fits backend, client, infrastructure, SRE, security, and general software engineering interviews. The interviewer does not merely want a recitation from ClientHello to Finished. The candidate must explain how identity becomes bound to this handshake, which keys protect which stages, and why removing a network round trip creates a replay problem that the application must handle.

What the Interviewer Is Testing

First, can the candidate separate key exchange, authentication, and bulk encryption? The public key in the certificate normally verifies the CertificateVerify signature over the handshake transcript. It does not encrypt all subsequent business traffic. Symmetric traffic keys come from ECDHE, a PSK, and the HKDF-based key schedule.

Second, can the candidate place the encryption boundary accurately? The initial ClientHello and ServerHello expose information needed for negotiation. After processing ServerHello, both peers can derive handshake traffic keys. Those keys protect EncryptedExtensions, Certificate, CertificateVerify, and Finished. Separate application traffic keys then protect application data.

Third, can the candidate distinguish resumption from 0-RTT? Session resumption can shorten authentication while still completing a 1-RTT handshake. With 0-RTT, the client sends early data in its first flight. Both can involve a PSK, but only early data lacks freshness derived from the current ServerHello.

Fourth, can the candidate translate protocol risk into business semantics? TLS 1.3 gives early data weaker properties: it is not forward secret and has no guarantee of non-replay across connections. Enabling it cannot be decided solely from the HTTP method. Charging money, creating a session, incrementing a counter, issuing a reward, or consuming a one-time token changes the answer.

Fifth, can the candidate propose an observable rollout and debugging plan? A strong answer distinguishes a full handshake, 1-RTT resumption, and 0-RTT; checks tickets, ALPN, HelloRetryRequest, early-data acceptance or rejection, and HTTP 425 Too Early; and verifies the separate security channel from an edge TLS terminator to the origin.

Questions to Clarify First

• Which transport is in use? HTTPS over TCP and QUIC/HTTP/3 both use TLS 1.3 cryptography, but carry messages and establish connections differently. The baseline uses TCP.
• Is this a first or resumed connection? A first connection has no usable PSK and needs certificate authentication. A resumed connection can offer a previous ticket, but does not necessarily send 0-RTT.
• Does the server request a client certificate? Most web APIs authenticate only the server. mTLS adds the client's Certificate and CertificateVerify.
• Where does TLS terminate? If it terminates at a CDN or load balancer, the client authenticates that edge endpoint. Edge-to-origin traffic is a separate connection with its own encryption and identity decisions.
• What are the replay semantics of the operation? Is GET /rates truly read-only? Does it consume a one-time token, increment a billable counter, or trigger expensive work? An idempotency key on POST /transfers does not automatically remove every early-data risk.
• Do both sides implement HTTP early data correctly? The client must safely retry on the established connection if the TLS layer rejects early data or the server returns 425.

30-Second Answer Framework

“In a full TLS 1.3 handshake, the client sends a ClientHello with versions, cipher suites, and an ECDHE key share. The server selects parameters in ServerHello and returns its share. Both peers feed the ECDHE result and transcript into HKDF to derive handshake keys, so the extensions, certificate, signature, and Finished after ServerHello are encrypted. The client validates the chain, hostname, CertificateVerify, and Finished, then sends its own Finished. Separate application traffic keys protect subsequent data.

Resumption uses a PSK associated with a previous ticket and can avoid full certificate authentication. If 0-RTT is also enabled, the client sends early data with ClientHello. That data depends only on the PSK, is not forward secret, and can be replayed across connections. I would allow only explicitly retry-safe, side-effect-free reads. A transfer must wait for handshake completion, with consistent gateway policy, 425 Too Early, and normal retry support.”

Step-by-Step Deep Dive

Step 1: ClientHello supplies negotiation material

The client begins with ClientHello. It commonly contains a nonce, supported TLS versions, TLS 1.3 cipher suites, signature algorithms, supported key-exchange groups, one or more key_share values, and extensions such as SNI and ALPN. A TLS 1.3 cipher suite mainly selects an AEAD algorithm and the hash used by HKDF. Other extensions negotiate certificate signature algorithms and key-exchange groups.

This message is not yet protected by handshake traffic keys in ordinary TLS 1.3. SNI is also normally visible unless the peers successfully use ECH. Saying that TLS encrypts every field from the first byte ignores that the peers have not yet derived shared traffic keys for this connection.

The client's key share is an ephemeral ECDHE public value. Its corresponding private value remains local. The public value is not itself the shared secret. Each peer combines its private value with the other peer's public value to calculate the same ECDHE secret.

Step 2: ServerHello selects parameters and completes fresh key exchange

The server selects the TLS version, cipher suite, and acceptable key share, then sends ServerHello. With ECDHE, it also supplies its ephemeral public value. ClientHello plus ServerHello determines the cryptographic parameters, and both peers can now feed the ECDHE secret into the TLS 1.3 HKDF key schedule.

If the client did not offer a share in a group the server accepts, the server can send HelloRetryRequest and require another ClientHello with a selected group. That costs another round trip, and an original early-data attempt cannot simply continue as the normal successful path. An intermittent extra RTT in production should prompt an HRR check rather than an automatic assumption of network jitter.

After ServerHello, both peers can derive client and server handshake traffic secrets. The protocol protects subsequent handshake messages with those keys. A passive observer cannot read the certificate or most later extensions, although record sizes, timing, and initial information not hidden by ECH remain observable.

Step 3: Server parameters, certificate, and transcript signature establish identity

The server next sends encrypted EncryptedExtensions, containing selections for extensions such as ALPN. It sends CertificateRequest if it wants client authentication. A typical one-way HTTPS handshake then sends the server's Certificate, CertificateVerify, and Finished.

Those messages have distinct jobs:

The client validates the chain, validity interval, hostname, and permitted signature algorithms according to its PKI policy, then verifies the CertificateVerify signature over the transcript. This binds control of the certificate's private key to this ClientHello, ServerHello, and negotiated parameter set. An attacker cannot transplant a signature from an unrelated handshake.

Step 4: Finished completes the handshake and separates application keys

The server's Finished is a verification value derived from the transcript and a handshake secret. A successful check tells the client that the observed negotiation was not modified and that the peer possesses the corresponding handshake key material. Accepting data without certificate authentication or Finished verification would discard TLS identity and integrity guarantees.

The client then sends its own Finished. If the server requested mTLS, the client sends its certificate and CertificateVerify first. The peers protect application data with application traffic secrets instead of continuing to reuse handshake keys. TLS 1.3 can later use KeyUpdate to move to new application traffic keys.

Forward secrecy comes from ephemeral (EC)DHE. If peers erase ephemeral private values and obsolete traffic secrets, a future leak of the server's long-term certificate private key should not decrypt captured application traffic from those completed full handshakes. The certificate key authenticates; it is not the sole source of forward secrecy.

Step 5: Session tickets turn later connections into PSK resumption

After a full handshake, the server can send NewSessionTicket. The client stores the ticket and associated resumption secret. On a later connection, it offers the ticket identity in pre_shared_key and uses a binder to prove possession of the corresponding PSK. If the server accepts it, the PSK authenticates the resumed connection, normally removing the need to send the certificate chain and CertificateVerify again.

Resumption does not require giving up fresh ECDHE. TLS 1.3 supports PSK-only and PSK combined with ECDHE. Production designs commonly care about PSK+DHE because it preserves resumption's authentication and computation benefits while incorporating fresh Diffie-Hellman material into ordinary 1-RTT application traffic. PSK-only has different properties, so the answer should name the selected mode.

A ticket is not a permanent login credential. It has a lifetime, bound cryptographic parameters, server key rotation, and cluster-sharing policy. If a multi-region service cannot consistently decrypt or validate a ticket, falling back to a full handshake or declining resumption is a valid compatibility branch. Chasing a higher resumption rate does not justify an unlimited ticket-key lifetime.

Step 6: 0-RTT puts early data in the first flight

If a ticket permits early data, the client can send ClientHello and application data in the resumed connection's first flight. Early data is encrypted with a client early traffic secret derived from the PSK. At send time, the client has not received this connection's ServerHello.

That reduces latency but creates two critical weaknesses:

1. Early data is derived from the PSK without this connection's ECDHE exchange, so it is not forward secret.
2. It does not depend on this server nonce and ServerHello, so the protocol cannot guarantee that the same ciphertext will not be replayed on another connection.

The server can accept or reject the TLS early-data batch. If it rejects it, the client must retransmit requests that still need execution after the normal handshake completes. Applications already face uncertainty when a server may have processed a request but the client did not receive the result. 0-RTT additionally lets an attacker deliberately create cross-connection duplicates.

Step 7: Decide eligibility from business side effects

Without extra information, RFC 8470 permits clients to use safe HTTP methods in early data and prohibits unsafe or unknown methods. The method is only a first filter. Resource behavior determines the actual risk.

An idempotency key does not by itself justify enabling 0-RTT for transfers. The idempotency record must be consistent across every processing node, committed atomically at the correct transaction boundary, and cover audit, notification, limit, and fraud side effects. Replaying a stolen request can also pin or consume the key. The safer policy is still to wait for handshake completion for high-risk writes.

Step 8: Make gateway, origin, and client policy consistent

HTTP defines Early-Data: 1 and 425 Too Early. When a gateway forwards a request that may have arrived in early data on a previous hop, it preserves the risk signal. An origin that cannot safely process the request returns 425. The client retries on the connection after handshake completion, and that retry must not use early data again.

Every edge instance must handle the same request class consistently. If one instance executes immediately while another waits for handshake completion or rejects, an attacker can exploit multi-instance differences to duplicate effects. Controls include:

• Disable 0-RTT by default and allow only explicitly registered read-only resources.
• Limit ticket lifetime, early-data size, and the acceptance window.
• Use shared or consistently partitioned anti-replay state while recognizing that it reduces risk rather than replacing application semantics.
• Reject early data as a whole under load so replay cannot amplify expensive work.
• Ensure the CDN, reverse proxy, and origin all understand Early-Data and 425.

Strong Sample Answer

“I will use a full ECDHE handshake over TCP with server certificate authentication as the baseline.

The client sends ClientHello with supported versions, TLS 1.3 cipher suites, signature algorithms, key-exchange groups, and an ephemeral key share, plus possible SNI and ALPN extensions. The server selects parameters in ServerHello and returns its key share. Both peers feed the ECDHE result and transcript into HKDF to derive handshake traffic keys. After the key-exchange phase, EncryptedExtensions, the server certificate, CertificateVerify, and Finished are encrypted.

The certificate supplies a trust chain for the server identity. CertificateVerify signs this handshake transcript with the certificate's private key, binding identity to this negotiation. Finished authenticates transcript integrity and confirms possession of the handshake keys. After the client validates the chain, hostname, signature, and Finished, it sends its own Finished, and the peers switch to separate application traffic keys. The certificate public key verifies identity; it does not encrypt all business data. Forward secrecy primarily comes from ephemeral ECDHE and secret erasure.

A later connection can resume with the PSK associated with NewSessionTicket. It can use a normal PSK+DHE 1-RTT handshake or optionally use 0-RTT. With 0-RTT, the client sends early data beside ClientHello, but those bytes are protected only by PSK-derived keys, are not forward secret, and can be replayed across connections.

I would therefore never send POST /transfers in 0-RTT. Even with an idempotency key, transfer, audit, limit, and notification effects must all be proven duplicate-safe. GET /rates enters an allowlist only if it is a pure read, safely retryable, and has no one-time token or unacceptable side effect. The gateway and origin propagate Early-Data: 1, return 425 Too Early when unsafe, and the client retries after handshake completion. During rollout, I separately measure full handshakes, 1-RTT resumptions, and 0-RTT, then verify ticket acceptance, HRR, the rejection path, and cross-node policy.”

Common Mistakes

• Saying the certificate public key encrypts all later traffic → TLS 1.3 business traffic uses symmetric traffic keys → separate certificate signature verification from ECDHE/PSK and HKDF.
• Saying everything is encrypted from ClientHello onward → initial negotiation precedes handshake-key derivation → place the boundary after ServerHello for subsequent handshake messages.
• Validating only the chain and omitting the transcript → identity must be bound to this negotiation → explain the separate roles of CertificateVerify and Finished.
• Equating resumption with 0-RTT → a resumed connection can wait for a 1-RTT handshake → describe PSK resumption first and early data as optional.
• Treating 0-RTT as a free RTT reduction → early data is not forward secret and can be replayed → map the risk to application effects.
• Automatically allowing every GET → a GET can consume a token, bill usage, or trigger costly work → allowlist according to actual resource semantics.
• Assuming an idempotency key solves transfer replay → cluster consistency and surrounding effects can still duplicate → wait for handshake completion on high-risk writes.
• Configuring only the CDN and ignoring the origin → TLS termination and HTTP forwarding cross two security boundaries → align edge, gateway, origin, client, and 425 behavior.

Follow-up Questions

Follow-up 1: Why is TLS 1.3 faster than TLS 1.2?

A typical full TLS 1.3 handshake can negotiate parameters and authenticate the server within one network round trip, while removing obsolete algorithms and several unnecessary messages from older designs. Its more unified key schedule and resumption mechanism also help. Total request latency still includes DNS, TCP, server processing, and application data. “TLS 1.3 is 1-RTT” does not mean an entire request always costs only one RTT.

Follow-up 2: What happens to historical traffic if the certificate private key leaks?

If those full handshakes used ephemeral ECDHE and the implementation erased ephemeral private values and obsolete traffic secrets, leaking only the long-term certificate key should not decrypt previously captured application traffic. That is the value of forward secrecy. A leaked ticket encryption key, PSK, session secret, or endpoint traffic secret has a different impact and must be evaluated against ticket lifetimes, logs, and rotation.

Follow-up 3: Why does an anti-replay store not make every request safe for 0-RTT?

A global multi-region system cannot easily make every ticket and early-data acceptance strongly consistent and single-use without adding latency. Network partitions, node state, ticket rotation, and concurrent attacker replays create boundaries. Protocol controls can limit the window or number of successful replays, but the application must still assume duplicate requests can occur and restrict early data to suitable operations.

Follow-up 4: How do you verify whether production used a full handshake, resumption, or 0-RTT?

In an authorized test environment, use openssl s_client -connect api.example:443 -servername api.example -tls1_3 -alpn h2 to inspect the version, certificate, and ALPN. Save and reuse a session, then observe whether it resumes and whether early data is accepted. Server telemetry should record the handshake mode and rejection reason without sensitive contents. Decrypt packet captures only in a controlled environment with client-exported session keys, then clean them up.

Follow-up 5: Is 425 Too Early an outage?

Not necessarily. It means the server refuses replay risk and is a normal early-data control path. The client should retry after handshake completion, and the retry must not use early data. If users see repeated failures, verify the client's retry implementation, propagation of Early-Data, consistency across server instances, and whether an unsuitable endpoint was mistakenly added to the 0-RTT allowlist.