How TLS 1.3 Works

TL;DR: In TLS 1.3 (RFC 8446, revised in July 2026 as RFC 9846) the client sends a key share in its first message, the server answers with its own, and both derive fresh session keys from an ephemeral Diffie-Hellman exchange, which gives forward secrecy. The server sends its certificate and a CertificateVerify signature over the handshake transcript, proving it holds the certificate's private key. Both sides send Finished messages, MACs over the whole transcript, so any tampering with the negotiation is detected. Application data then flows under AES-GCM or ChaCha20-Poly1305. One round trip, and no legacy options to downgrade to.

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

1. 1An attacker obtains a copy of a website's certificate (the public certificate file, not the private key). Can they impersonate the site over TLS?

   Commit to a guess, then reveal

What TLS has to achieve

A client connecting to a server across a network it does not control needs three things:

1. Confidentiality: nobody on the path can read the traffic.
2. Integrity: nobody can change it undetected.
3. Server authentication: the client is talking to the real server, not an impostor.

TLS 1.3, published as RFC 8446 in 2018 and revised as RFC 9846 in July 2026 (still TLS 1.3, not a new version), achieves all three in one round trip and removed the options that made earlier versions fragile: RSA key transport (no forward secrecy), static Diffie-Hellman, CBC-mode ciphers, compression and renegotiation.

The handshake, message by message

What each piece protects against:

If the client's key share uses a group the server does not support, the server sends a HelloRetryRequest naming one it does, costing one extra round trip.

Inside the key schedule

TLS 1.3 never uses the Diffie-Hellman output directly. It feeds it through HKDF in three stages, deriving a separate secret for each purpose with a text label, so a key used for one job can never be mistaken for another.

The labels are worth recognising (c hs traffic, s ap traffic, res master) because they appear in key-log files used to decrypt captures during debugging. RFC 9846 renamed the secrets to drop "master" from their names, while keeping the original label strings on the wire for compatibility.

Version fields and downgrade protection

TLS 1.3 hides its own version number from middleboxes that broke when it changed. The legacy_version field in ClientHello and ServerHello is fixed at 0x0303, the number for TLS 1.2, and the real version is negotiated in the supported_versions extension. To stop an attacker forcing a 1.3-capable client and server down to 1.2, a TLS 1.3 server that ends up negotiating 1.2 writes a fixed sentinel, the ASCII bytes "DOWNGRD" followed by 01, into the last 8 bytes of its random value. The random is signed in the handshake, so the attacker cannot remove it, and a 1.3-capable client that sees it aborts. A HelloRetryRequest, by contrast, is recognised by a different fixed random: the SHA-256 hash of the string "HelloRetryRequest".

Cipher suites and usage limits

TLS 1.3 defines five cipher suites, each naming an AEAD and a hash for HKDF: TLS_AES_128_GCM_SHA256 (mandatory to implement), TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, and two CCM suites used mainly on constrained devices. Key exchange and signature algorithms are negotiated separately, which is why the list is short.

Keys also wear out. The RFC limits AES-GCM to 2^24.5 full-size records under one set of keys, and RFC 9846 makes updating keys before the limit a requirement. A full-size record carries 2^14 bytes, so one key set covers about 2^38.5 bytes, roughly 389 GB, before a KeyUpdate message must ratchet the traffic keys forward. Short web connections never get close; long-lived tunnels, replication links and gRPC streams can.

0-RTT and its catch

A client that has connected before can resume with a pre-shared key and send data in its very first flight, called 0-RTT or early data. It saves a round trip, but early data can be replayed: an attacker who captures it can send it again. Servers should accept 0-RTT only for requests that are safe to repeat, such as plain reads, and never for actions like payments.

The details that make this an engineering decision rather than a slogan:

• No forward secrecy for early data. It is encrypted with keys derived from the resumption secret alone, before any fresh Diffie-Hellman, so whoever later obtains that secret (or the server's session-ticket encryption key) can decrypt it.
• Replay windows. Session tickets may live for at most 7 days (604,800 seconds). The RFC describes anti-replay options, single-use tickets, recording ClientHellos and freshness checks with windows on the order of ten seconds, but none prevents replay across servers that do not share state.
• HTTP's answer. RFC 8470 lets a CDN or proxy forward early data with an Early-Data: 1 header, and lets the origin respond 425 Too Early to make the client retry after the handshake completes. Accept early data only for idempotent methods, and enforce it at the edge.
• Resumption without fresh key exchange. A resumption mode that uses the PSK alone (no new Diffie-Hellman) has the same weakness as early data for the whole session. Prefer the mode that adds a fresh key share, and rotate ticket-encryption keys frequently.

Encrypted Client Hello

Without ECH, the server name travels in plaintext in the ClientHello, which lets any network observer, and any censor, see which site on a shared IP a user is visiting. Encrypted Client Hello, standardised as RFC 9849 in March 2026, splits the ClientHello in two. The real ("inner") ClientHello, including the true server name, is encrypted with HPKE to a public key the server publishes, usually in a DNS HTTPS record. The visible ("outer") ClientHello carries only a shared public_name, such as the CDN's name. Clients that do not have a real config send fake "GREASE" ECH extensions, so the presence of ECH does not single out its users. If the server rejects the config, it returns fresh retry_configs authenticated for the public name, and the client retries once; it must never fall back to sending the real name in plaintext. ECH protects the name, not the destination address: a site with its own dedicated IP is still identifiable.

Post-quantum key exchange

An attacker who records TLS traffic today can decrypt it later if they ever break the key exchange, which is the "harvest now, decrypt later" threat a large quantum computer would create for elliptic-curve Diffie-Hellman. The response is a hybrid key exchange: run X25519 and ML-KEM-768 (the lattice-based key encapsulation mechanism NIST standardised as FIPS 203 in August 2024) together, and derive keys from both shared secrets, so the connection stays secure unless both are broken.

The hybrid group is defined in RFC 10024 (August 2026), but deployment ran ahead of the RFC: Chrome switched its default from an early Kyber draft to ML-KEM in Chrome 131, and Apple enabled X25519MLKEM768 by default for TLS 1.3 in iOS 26's networking frameworks. Two caveats belong in an interview answer. Certificates and handshake signatures are still classical, which matters for live impersonation by a future quantum attacker, not for recorded traffic. And the larger ClientHello no longer fits in a single packet, which has broken some middleboxes that assumed it would.

Mutual TLS

Normally only the server authenticates. In mutual TLS (mTLS) the server also requests a certificate from the client, and the client proves possession of its private key in the same way. Service meshes and internal APIs use mTLS so each service has a cryptographic identity. The trust model differs from the public web: you usually run your own internal certificate authority and decide which identities may call which services, which still requires authorization on top.

What TLS does not protect

TLS is often treated as "security done". It is a channel protection, and engineers should know its edges:

• The endpoints. A compromised server or client sees plaintext. TLS protects data between them.
• Data at rest. Once received, data is stored however the application stores it.
• Authorization. TLS tells the server the connection is encrypted and, with mTLS, who the client is. It does not decide what that client may do.
• Metadata. IP addresses, timing and sizes are visible. The server name in the ClientHello is visible unless Encrypted Client Hello is in use.
• Bad validation. Code that disables certificate checks (verify=False, "accept all certificates") keeps encryption but loses authentication, so any interceptor can impersonate the server.

That last item matters for AI integrations. Agent frameworks, notebooks and internal tools that call model APIs or tool servers with verification switched off "to make it work" are open to interception on any network the attacker can reach.

Worked example: a latency and byte budget

A client is 80 ms round-trip from a server.

Now add the post-quantum share: the ClientHello grows by about 1,184 bytes, so it spans two TCP segments instead of one. On a healthy path that costs almost nothing; on paths with middleboxes that expect a one-packet ClientHello, connections fail outright, which is why browsers rolled the change out gradually and kept the ability to disable it by policy.

For a long-lived AES-GCM connection, budget the 389 GB per-key-set limit: a replication link moving 1 GB a minute reaches it in about six and a half hours, so the implementation must send KeyUpdate on schedule.

Misconceptions interviewers listen for

• "TLS 1.3 hides which site I visit." Only with ECH; and even then, not the destination IP.
• "An observer sees the server certificate." In TLS 1.3 it is encrypted under the handshake keys, although anyone can fetch it by connecting.
• "0-RTT is just a faster handshake." It is replayable and not forward secret.
• "The post-quantum hybrid makes TLS quantum-safe." It protects the key exchange against recorded-traffic attacks; authentication is still classical.
• "RFC 9846 is TLS 1.4." It revises TLS 1.3.
• "Every resumed session has forward secrecy." Not in PSK-only mode, which depends on the ticket key.

What if · interview follow-ups

Hold your answer as the constraints change

You run TLS termination for a payments company: a CDN in front of web and API traffic, session resumption enabled, and long-lived connections between data centres. The interviewer changes one condition at a time.

1. 1

   Start here

   What if the server's certificate private key leaks tomorrow?

   Nudge meAnswer it out loud, then reveal

Revising, not practising? Show every answer

Primary references

• RFC 9846: the July 2026 revision of TLS 1.3, accessed 6 November 2026.
• RFC 9525: TLS service identity verification, accessed 6 November 2026.

How this shows up in interviews

"Walk me through a TLS handshake" is a staple. The strong answer goes beyond the message names: it says what each step defends against, explains forward secrecy, names CertificateVerify as the proof of key possession, and lists what TLS does not cover. Follow-ups test depth: 0-RTT replay, how certificate validation can fail, and how mutual TLS changes the trust model.

Say it in 30 seconds: "The client sends an ephemeral key share, the server replies with its own, and both derive session keys from ECDHE, which gives forward secrecy. The server sends its certificate and a CertificateVerify signature over the transcript, proving it holds the private key for that name, and both sides send Finished MACs so tampering with the negotiation is caught. Then data flows under AES-GCM. It's one round trip. TLS protects the channel, not the endpoints, the data at rest or authorization."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

1. 1Why does TLS 1.3 sign the whole handshake transcript in CertificateVerify rather than just signing the server's key share?

   Answer it, then reveal

2. 2A team says their agent's calls to an internal tool server are secure because they use HTTPS, but the client is configured to skip certificate verification. What is actually protected?

   Answer it, then reveal

3. 3How does a TLS 1.3 client detect that an attacker forced the connection down to TLS 1.2?

   Answer it, then reveal

4. 4Why is 0-RTT early data not forward secret?

   Answer it, then reveal

5. 5What does Encrypted Client Hello hide, and what does it not?

   Answer it, then reveal