Cryptography / Protocols

TLS 1.3 Handshake & Network Encryption

Transport Layer Security (TLS) 1.3 is the foundational security protocol of the internet, providing confidentiality, integrity, server authentication, and — for its standard full handshake — Perfect Forward Secrecy over TCP networks. Standardized in RFC 9846 — which obsoletes RFC 8446, the original TLS 1.3 specification, rather than merely amending it — TLS 1.3 streamlines the handshake phase to 1-RTT by combining key exchange with initial parameters and deprecating legacy, insecure ciphers.

TLS 1.3 Handshake Architecture (1-RTT)

Unlike a full TLS 1.2 handshake, which required 2 round-trips (2-RTT) before transmitting encrypted application data — TLS 1.2’s abbreviated (session-resumption) handshake could complete in 1-RTT, so “2-RTT” describes the full handshake specifically, not TLS 1.2 as a whole — TLS 1.3 establishes an encrypted channel in just 1-RTT for its full handshake:

TLS 1.3 certificate-authenticated 1-RTT handshake: ordinary X25519 uses two Diffie-Hellman shares, while X25519MLKEM768 uses an ML-KEM encapsulation key plus X25519 share from the client and an ML-KEM ciphertext plus X25519 share from the server; optional ECH is a separate ClientHello extension

Step-by-Step Handshake Sequence

1. ClientHello + Key Share: Client sends supported cipher suites, protocol version (TLS 1.3), and an ephemeral key share for its chosen group. That may be a finite-field DH value, an ECDH share such as X25519, or the hybrid X25519MLKEM768 group (RFC 10024 §4.1), whose client-side share concatenates a freshly generated ML-KEM-768 encapsulation key with an X25519 share — not an ML-KEM ciphertext. Optional ECH is a separate extension carrying an encrypted ClientHelloInner; it is not part of key_share.
2. ServerHello + Key Share: Server selects a cipher suite from the client’s offered list and completes the negotiated group’s key-establishment step: a finite-field or elliptic-curve Diffie-Hellman response for an ordinary DH group, or ML-KEM encapsulation against the client’s encapsulation key for X25519MLKEM768 (RFC 10024 §4.2), producing a ciphertext sent alongside the server’s X25519 share. The server derives the Handshake Secret via HKDF from the resulting shared secret; the client derives the same secret by processing the ordinary DH response or decapsulating the hybrid ciphertext. The Main Secret (RFC 9846 §7.1 — called “Master Secret” in the original RFC 8446 wording) is derived immediately afterward via a further HKDF-Extract step; it does not wait for either side’s Finished message. TLS 1.3 negotiates the AEAD separately, so AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, and AES-CCM remain independent of the selected key-establishment group.
3. Encrypted Extensions & Certificate: All subsequent handshake messages are encrypted using the derived handshake key. Server sends its X.509 certificate and CertificateVerify signature, then its own Finished message. At this point the server can already derive its application traffic secret — its Derive-Secret call only needs the transcript through the server’s own Finished, which is why TLS 1.3 permits the server to send 0.5-RTT application data before the client’s flight arrives.
4. Client Finished: The client verifies the server’s handshake transcript, derives its own handshake MAC, and sends its Finished message (preceded by the client’s Certificate/CertificateVerify only if the server requested client authentication). Once the client’s Finished is added to the transcript, both sides can derive the resumption secret, which specifically requires the transcript through the client’s Finished (unlike the application traffic secrets, which only needed the transcript through the server’s Finished) — this client flight happens before ordinary bidirectional application data, per RFC 9846.

This is the handshake as it runs directly over TCP for HTTP/2 and earlier. HTTP/3 does not reuse the TLS record layer at all — it runs over QUIC (RFC 9000), which uses TLS 1.3 (RFC 9001) only for the handshake and key negotiation, then applies its own QUIC packet protection (built on the negotiated AEAD keys) rather than framing application data inside ordinary TLS records. Describing HTTP/3 traffic as “the TLS record layer over AES-GCM” conflates the two transports.

TLS Protocol Version & Security Status Matrix

Advanced TLS 1.3 Features & Security Trade-offs

1. 0-RTT Early Data & Replay Attack Vulnerability

TLS 1.3 allows returning clients to resume sessions and send data in the very first packet (0-RTT). However, because 0-RTT data is transmitted before server handshake completion, an attacker can capture and replay 0-RTT packets.

2. Encrypted Client Hello (ECH, RFC 9849)

In standard TLS 1.3, the Server Name Indication (SNI) header in ClientHello remains unencrypted, allowing network observers to monitor target domain destinations. Encrypted Client Hello (ECH), standardized as RFC 9849 in March 2026 after progressing through the draft-ietf-tls-esni series, addresses this: the client sends an unencrypted, innocuous-looking ClientHelloOuter and wraps the true handshake parameters — including the real SNI — inside an encrypted ClientHelloInner, carried as an extension and encrypted (via HPKE) under a public key published in the server’s DNS HTTPS record. ECH does not encrypt the entire ClientHello; the outer message is still sent in the clear, but the sensitive fields it would otherwise expose are hidden inside the encrypted inner payload, which is what defeats passive SNI eavesdropping.

TLS Ecosystem Mechanics

Beyond the core handshake, several mechanisms determine how TLS 1.3 actually behaves in a real deployment:

• What a “cipher suite” means in TLS 1.3: TLS 1.2 cipher suite names (e.g., TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) bundled key exchange, authentication, bulk cipher, and hash into one negotiated unit. TLS 1.3 splits this apart: the cipher suite now names only the AEAD algorithm and hash (e.g., TLS_AES_256_GCM_SHA384), while key exchange (supported_groups / key_share) and authentication (the signature algorithm used in CertificateVerify, via signature_algorithms) are negotiated as separate, independent extensions. A TLS 1.3 “cipher suite” is a narrower concept than its TLS 1.2 namesake.
• ALPN (Application-Layer Protocol Negotiation, RFC 7301): A ClientHello extension listing application protocols the client supports (e.g., h2 for HTTP/2, http/1.1); the server picks one and returns its choice in EncryptedExtensions. This is how a single HTTPS port (443) serves both HTTP/1.1 and HTTP/2 clients without a separate handshake round-trip to negotiate the application protocol afterward.
• Session resumption via tickets: Rather than repeating a full handshake, TLS 1.3 lets the server issue one or more opaque NewSessionTicket messages (post-handshake). The ticket itself doesn’t necessarily contain the resumption secret directly — it’s implementation-defined and opaque to the client, either a reference into server-side session state or self-contained encrypted state. The actual resumption PSK is derived from the connection’s resumption_master_secret together with a per-ticket ticket_nonce via HKDF-Expand-Label, so each issued ticket yields a distinct PSK even though every ticket for a connection traces back to the same resumption secret. A returning client presents a ticket via the pre_shared_key extension, letting both sides skip straight to a PSK-based (optionally PSK+DHE) abbreviated handshake. Tickets should be short-lived and, ideally, single-use or anti-replay-protected server-side, since ticket-based resumption without psk_dhe_ke forgoes forward secrecy for that resumed session (see the version matrix above).
• Client authentication / mTLS: The server can request a client certificate via CertificateRequest; the client responds with its own Certificate and CertificateVerify inside the client’s encrypted post-ServerHello flight described in step 4. Mutual TLS (mTLS) is this mechanism used for service-to-service or zero-trust network authentication, where both directions authenticate via certificates rather than relying solely on server-side authentication plus an application-layer credential.
• HelloRetryRequest (HRR): If the server doesn’t support any group the client offered a key_share for (or wants a different one), it responds with a HelloRetryRequest instead of ServerHello, asking the client to resend ClientHello with an acceptable group. This costs an extra round trip (making that handshake 2-RTT instead of 1-RTT) but lets the server participate in group selection without requiring the client to guess correctly up front or send key shares for every group it supports.
• KeyUpdate: For long-lived connections, either side can send a KeyUpdate message to ratchet the traffic keys forward — deriving fresh application traffic keys from the current ones via a one-way HKDF step — without a full re-handshake. This bounds how much ciphertext is protected under any single key (useful for staying within AEAD’s per-key data limits on very long connections) and protects earlier key generations after the fact, provided the superseded secrets are actually erased. It does not provide post-compromise recovery: because each new generation is derived deterministically from the current one, an attacker who holds the current traffic secret can derive every later generation too — KeyUpdate ratchets existing key material forward, it doesn’t inject the fresh entropy a new (EC)DHE exchange would.
• TLS vs. QUIC boundary: As noted above, HTTP/3 runs over QUIC, which uses TLS 1.3 only for its handshake and key negotiation (RFC 9001) — QUIC then does its own packet protection and has its own loss-recovery and multiplexing layer entirely separate from the TCP-carried TLS record layer HTTP/1.1 and HTTP/2 use.

Primary references

• RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 — IETF RFC 9846 (a backward-compatible update that obsoletes RFC 8446, the original TLS 1.3 specification)
• RFC 9849: TLS Encrypted Client Hello — IETF RFC 9849
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1 — IETF RFC 8996