TLS 1.3 Handshake

TLS 1.3 compresses the handshake to 1-RTT, 0-RTT, or even zero round-trips—achieved by removing static RSA, enforcing forward secrecy, and moving key negotiation to the ClientHello. A clean protocol design, at the cost of losing replay protection for 0-RTT.

Overview

TLS 1.3 (RFC 8446, 2018) is the most significant overhaul of TLS 1.2. Its core strategy can be summarized in one sentence: the client no longer "asks the server what it wants to use," but instead guesses directly—including an ECDHE public key (key_share) in the ClientHello, betting that the server supports x25519 (a bet that almost always pays off). Thus, the two round-trips of "negotiate algorithms, then exchange keys" in TLS 1.2 collapse into one; with session tickets, it can even be zero round-trips (0-RTT).

There are four design goals:

1. Reduce handshake round-trips: 2-RTT → 1-RTT (first time), 0-RTT (reconnection)
2. Remove insecure algorithms: Static RSA key exchange, CBC, RC4, MD5/SHA-1—all historically problematic algorithms are removed
3. Encrypt more handshake messages: Everything after ServerHello is encrypted; passive eavesdroppers cannot even see the certificate
4. Simplify: Reduced from ~100 cipher suites to 5

Key differences from TLS 1.2 at a glance:

1-RTT Full Handshake Flow

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello<br>key_share(x25519 public key), cipher_suites,<br>supported_groups, signature_algorithms
    Note over S: Shared key can already be computed<br>→ All subsequent messages are encrypted
    S->>C: ServerHello (key_share)<br>🔒 EncryptedExtensions<br>🔒 Certificate + CertificateVerify<br>🔒 Finished
    Note over C: Verify certificate and signature,<br>compute the same key
    C->>S: 🔒 Finished + Application Data
    Note over C,S: Data is already in transit by the end of the first RTT<br>(TLS 1.2 requires two RTTs)

Three design points are hidden in this flow:

key_share: Early key negotiation. The client attaches an ECDHE public key for several elliptic curves (x25519 32 bytes, secp256r1 65 bytes). The server selects one curve and returns its own public key—both parties complete the Diffie-Hellman exchange within the first round-trip. What if the guess is wrong? The server responds with a HelloRetryRequest specifying the curve, and the client resends the ClientHello, degrading to 2-RTT—this rarely happens in practice.

Decoupling authentication and confidentiality. In TLS 1.2, static RSA tied two things together: the server's private key both proved identity and participated in key decryption—if the private key was leaked, all recorded past traffic could be decrypted. In TLS 1.3, keys come only from fresh ECDHE each time (forward secrecy). The certificate private key does only one thing: sign the handshake records (CertificateVerify) to prove "I am indeed the owner of this domain."

Cipher suites are reduced to combinations of AEAD + hash:

Key Derivation: HKDF

TLS 1.3 uses HKDF instead of TLS 1.2's PRF. The derivation chain is a three-level "key ladder":

Early Secret     = HKDF-Extract(salt=0, PSK or 0)          ← 0-RTT keys derived from this level
Handshake Secret = HKDF-Extract(Early Secret, ECDHE shared key) ← Handshake encryption keys
Master Secret    = HKDF-Extract(Handshake Secret, 0)        ← Application data keys

Each Expand step mixes in the transcript hash (hash of all handshake messages so far)—so even if two handshakes use the same PSK, if any single message differs by one byte, the derived keys will be completely different. This is the root of handshake tamper resistance: if any message is modified, the Finished verification values calculated by both sides will not match.

0-RTT PSK: Zero Round-Trips for Reconnection

After the first handshake, the server issues a session ticket (essentially a PSK). During reconnection, the client includes the PSK identifier and binder in the ClientHello, directly attaching encrypted application data (early data) in the same packet—the server processes it immediately after verifying the PSK, without waiting a single round-trip.

The cost is reduced security; three points must be understood:

• Replay attacks: An attacker can resend captured 0-RTT packets verbatim, causing the server to process the early data again. The protocol layer does not provide complete defense; application-layer self-protection is required—only idempotent operations should be placed in 0-RTT (e.g., HTTP GET/HEAD), which is exactly how major CDNs implement it.
• No forward secrecy: Early data keys are derived only from the PSK; if the PSK is leaked, all past 0-RTT data can be decrypted (the 1-RTT part is unaffected because it mixes in new ECDHE).
• The server can limit exposure using max_early_data_size, or simply reject early data to force a fallback to 1-RTT.

Encrypted ClientHello (ECH)

The last remaining plaintext in TLS 1.3: the ClientHello itself—the SNI (target domain) allows intermediate devices to still inspect/block based on domain. ECH (successor to ESNI, RFC draft) fills this gap:

1. The server publishes the ECH public key in DNS HTTPS records (type 65).
2. The client encrypts the real ClientHello (including the real SNI) as an inner layer, while the outer layer uses a cover domain (e.g., cloudflare-ech.com).
3. Only the server holding the ECH private key can decrypt the inner layer; observers on the path only see the cover domain.

Combined with DoH/DoT (DNS queries themselves are also encrypted, see DNS Privacy), the metadata "which website the user visited" is finally truly hidden.

Related

The full handshake of TLS 1.2 and its historical baggage are covered in TLS 1.2 Handshake; how certificate chains are verified is covered in Certificates and PKI; QUIC builds TLS 1.3 directly into the transport layer, see HTTP/3.

References

• RFC: 8446 (Appendix D contains security analysis of 0-RTT)
• ECH: draft-ietf-tls-esni
• Tools: openssl s_client -tls1_3 -connect host:443 · Wireshark filter tls.handshake.type
• Visualization: tls13.xargs.org (byte-by-byte illustration of the TLS 1.3 handshake, excellent)

Keywords: TLS 1.3, TLS1.3 handshake flow, 1-RTT, key_share, ECDHE, forward secrecy, 0-RTT, PSK, replay attack, session ticket, HKDF, transcript hash, ECH, SNI, cipher suite, TLS1.2 differences