TLS 1.3 Handshake and 0-RTT Resumption

TLS 1.3, released in 2018 (RFC 8446), was designed to fix the weaknesses accumulating in TLS 1.2 over a decade of real-world attacks. Earlier versions allowed negotiating weak cipher suites, supported export-grade cryptography, and required multiple round trips before data could flow. TLS 1.3 removes all deprecated algorithms and streamlines the handshake to a single round trip in the normal case, dramatically improving both security and performance.

In TLS 1.3, the client and server complete the handshake in 1-RTT (one round trip). The client sends a ClientHello that includes supported cipher suites and a key share (using Diffie-Hellman). The server responds with a ServerHello, its own key share, a certificate, and the first encrypted application data — all in one flight. The client then verifies the certificate and sends a Finished message before exchanging application data.

TLS 1.3 mandates ephemeral key exchange — it removed RSA key exchange entirely. All key exchange must use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) or DHE (Diffie-Hellman Ephemeral). The word 'ephemeral' means a fresh key pair is generated for every session. This is the foundation of perfect forward secrecy: compromising the server's long-term private key cannot decrypt past sessions because each session used a unique temporary key.

Perfect Forward Secrecy (PFS) ensures that even if an attacker records all encrypted traffic today and obtains the server's private key in the future, they still cannot decrypt old sessions. In TLS 1.2 with RSA key exchange, the server's private key could decrypt the pre-master secret in any past session — a catastrophic failure. TLS 1.3's ephemeral DH keys mean that each session derives its own keys, and those ephemeral keys are discarded after use.

TLS 1.2 supported over 300 cipher suites, many of them weak or broken. TLS 1.3 reduces this to just five cipher suites, all of which use AEAD (Authenticated Encryption with Associated Data): TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, and TLS_AES_128_CCM_8_SHA256. This eliminates entire attack categories like BEAST, POODLE, and FREAK that exploited weak cipher negotiation.

0-RTT (Zero Round Trip Time) resumption is an optional TLS 1.3 feature that allows a client to send application data on the very first message, before the handshake completes. It works by using a Pre-Shared Key (PSK) from a previous session. While 0-RTT dramatically reduces latency — critical for high-traffic APIs — it introduces a significant trade-off: the early data is not protected against replay attacks.

In a replay attack against 0-RTT data, an attacker who intercepts the early data message can re-send it to the server, potentially triggering the same action twice (e.g., a payment or a state change). TLS 1.3's specification explicitly warns that 0-RTT early data must only carry idempotent operations — ones that produce the same result regardless of how many times they are executed, like a GET request. Non-idempotent operations (POST, DELETE) should never use 0-RTT.

After a successful TLS 1.3 full handshake, the server issues a NewSessionTicket message containing a PSK (Pre-Shared Key) that the client stores. On reconnection, the client includes this PSK in its ClientHello using the pre_shared_key extension. The server recognizes it and either approves 0-RTT data or falls back to 1-RTT resumption. PSK tickets are time-limited and should be rotated frequently to limit their exposure window.

A major improvement in TLS 1.3 is that most of the handshake is encrypted, including the server certificate. In TLS 1.2, the server certificate was sent in plaintext, allowing a network observer to identify which domain the client was connecting to. TLS 1.3 encrypts the certificate and most subsequent handshake messages, reducing the metadata available to passive observers. Encrypted Client Hello (ECH) is an emerging extension that hides even the SNI (Server Name Indication) field.

TLS 1.3 removed numerous legacy features that had become liabilities: RSA key exchange (no forward secrecy), CBC mode cipher suites (vulnerable to padding oracle attacks), RC4 (completely broken stream cipher), export-grade cryptography (the cause of FREAK and Logjam), MD5 and SHA-1 in digital signatures, compression (the cause of CRIME), and renegotiation (the cause of multiple attacks). By removing these, TLS 1.3 has a dramatically smaller attack surface.

Deploying TLS 1.3 correctly requires configuring your web server to prefer it while disabling TLS 1.0 and 1.1. Most modern web servers (Nginx, Apache, IIS) support TLS 1.3 natively. You should also ensure that OCSP Stapling is enabled to provide certificate revocation status without the client contacting the CA, and that HSTS headers prevent downgrade attacks to HTTP. Use tools like SSL Labs to verify your configuration achieves an A+ rating.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: TLS 1.3 completes the handshake in 1-RTT using only ephemeral DH key exchange for perfect forward secrecy, 0-RTT resumption enables faster reconnection using PSKs but is vulnerable to replay attacks and should only carry idempotent operations, and TLS 1.3 removes all legacy weak features — RSA key exchange, CBC ciphers, RC4, export crypto, and compression — dramatically reducing the attack surface. Next up we explore authenticated encryption algorithms like AES-GCM.