TLS 1.3 Explained: The Handshake That Protects the Internet

Every HTTPS connection, every API call, every WebSocket upgrade, every email delivery over STARTTLS – all of it runs over Transport Layer Security. As of early 2026, TLS 1.3 handles approximately 95% of encrypted web traffic according to Cloudflare’s radar data, up from 50% at its standardization in August 2018 (RFC 8446). The protocol processes an estimated 5 trillion handshakes per day across the global internet.

TLS 1.3 was not an incremental upgrade. It was a ground-up redesign that removed 20 years of accumulated cruft from its predecessors. The handshake dropped from two round trips to one. The cipher suite list shrank from over 300 options in TLS 1.2 to exactly five. RSA key exchange was eliminated entirely. CBC mode was eliminated entirely. Static Diffie-Hellman was eliminated entirely. Every connection now mandates ephemeral key exchange and forward secrecy. These were not optional features. They were structural requirements.

The IETF working group behind TLS 1.3 took four years and 28 drafts to complete the specification. The result is a protocol that is simultaneously faster, simpler, and more secure than anything that preceded it.

What TLS 1.3 Removed

Understanding TLS 1.3 requires understanding what it killed. Every removed feature had been the basis of a real-world attack.

RSA key exchange. In TLS 1.2, the client could encrypt a premaster secret directly to the server’s RSA public key. This provided no forward secrecy – compromise of the server’s private key retroactively decrypted every recorded session. The Bleichenbacher attack (1998) and its variants (ROBOT, 2017) exploited RSA PKCS#1 v1.5 padding in key exchange to decrypt traffic without the private key. TLS 1.3 mandates ephemeral Diffie-Hellman. RSA is allowed only for signatures, never for key transport.

CBC cipher suites. CBC mode with MAC-then-encrypt ordering was vulnerable to padding oracle attacks. BEAST (2011), Lucky13 (2013), and POODLE (2014) all exploited this pattern. TLS 1.3 permits only AEAD (Authenticated Encryption with Associated Data) ciphers: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305, AES-128-CCM, and AES-128-CCM-8.

Static DH parameters. TLS 1.2 allowed servers to reuse DH parameters across connections. The Logjam attack (2015) demonstrated that precomputing discrete logarithms for common 1024-bit DH groups allowed passive decryption of traffic from 8.4% of the top million HTTPS sites. TLS 1.3 mandates ephemeral key shares from a defined set of groups.

Renegotiation. TLS 1.2 renegotiation allowed mid-connection changes to cryptographic parameters, enabling the renegotiation attack (2009) where an attacker injected content at the beginning of a session. TLS 1.3 removed renegotiation entirely.

Compression. TLS-level compression enabled the CRIME (2012) and BREACH (2013) attacks, which recovered session cookies through adaptive compression side channels. Removed.

Custom DH groups. Gone. TLS 1.3 specifies exactly which groups are permitted: x25519, x448, secp256r1, secp384r1, secp521r1, and FFDHE groups 2048-8192. No negotiation of arbitrary parameters.

The removal list reads as a summary of TLS attacks from the past two decades. Each deletion closed a category of vulnerability, not merely a specific exploit.

The 1-RTT Handshake

TLS 1.2 required two round trips before application data could flow: the client sent ClientHello, received ServerHello + certificate + key exchange, sent its key exchange + Finished, and then received the server’s Finished. Two full round trips of latency before a single byte of application data.

TLS 1.3 completes the handshake in one round trip.

ClientHello

The client sends:

• Supported cipher suites (from the five permitted AEAD options)
• Key shares for one or more supported groups (typically x25519 and secp256r1)
• Supported signature algorithms for certificate verification
• Pre-shared key (PSK) extension if resuming a previous session
• Server Name Indication (SNI) identifying the target hostname

The critical change: the client speculatively includes key shares in the first message. In TLS 1.2, key exchange parameters were negotiated before key shares were sent, requiring an extra round trip. In TLS 1.3, the client guesses which groups the server will accept and includes key material for those groups upfront.

If the server does not support any of the client’s offered groups, it responds with a HelloRetryRequest specifying its preferred group, and the client retries – adding one round trip. In practice, this rarely occurs because x25519 is nearly universally supported.

ServerHello and Encrypted Extensions

The server responds with:

• Selected cipher suite (one of the five)
• Selected key share (the server’s ephemeral public key for the chosen group)
• Encrypted Extensions (server parameters that do not affect cipher negotiation)
• Certificate (the server’s X.509 certificate chain)
• CertificateVerify (a signature over the handshake transcript using the certificate’s private key)
• Finished (an HMAC over the entire handshake transcript)

Everything after the ServerHello is encrypted. This is another departure from TLS 1.2, where the certificate was sent in plaintext. In TLS 1.3, a passive observer sees the ClientHello (including SNI), the ServerHello, and then encrypted data. The certificate, extensions, and all subsequent communication are confidential.

Key Derivation

The handshake produces shared secrets through a carefully structured derivation using HKDF (HMAC-based Key Derivation Function), as specified in RFC 5869.

(EC)DHE shared secret
       |
       v
   HKDF-Extract → Handshake Secret
       |
       ├── HKDF-Expand → client_handshake_traffic_secret
       ├── HKDF-Expand → server_handshake_traffic_secret
       |
       v
   HKDF-Extract → Master Secret
       |
       ├── HKDF-Expand → client_application_traffic_secret
       ├── HKDF-Expand → server_application_traffic_secret
       └── HKDF-Expand → resumption_master_secret

The derivation schedule feeds the DH shared secret through multiple Extract-Expand stages, mixing in the handshake transcript hash at each step. This binds the derived keys to the specific handshake that produced them – any alteration to any handshake message changes all derived keys, preventing transcript manipulation.

The client and server derive separate traffic keys for each direction (client-to-server and server-to-client), and separate keys for the handshake phase and the application phase. The handshake keys protect the certificate and Finished messages. The application keys protect all subsequent data. Key separation ensures that compromise of one set of keys does not affect others.

Client Finished and Application Data

The client verifies the server’s certificate chain, checks the CertificateVerify signature against the handshake transcript, and verifies the server’s Finished HMAC. If all checks pass, the client sends its own Finished message and can immediately begin sending application data – in the same flight. One round trip total.

0-RTT Resumption

TLS 1.3 supports zero-round-trip resumption (0-RTT) for clients reconnecting to a server they have previously communicated with. During the initial handshake, the server issues a NewSessionTicket containing a pre-shared key (PSK). On reconnection, the client includes the PSK in its ClientHello along with “early data” – application data encrypted under a key derived from the PSK.

The server can process this early data before the handshake completes, eliminating the round-trip latency entirely.

0-RTT comes with a significant caveat: early data is not protected against replay attacks. An attacker who captures a 0-RTT ClientHello can retransmit it, and the server will process the early data again. For idempotent requests (GET requests, cache lookups), this is acceptable. For state-changing operations (POST requests, payment processing), replay is dangerous.

TLS 1.3 explicitly warns implementers about this tradeoff. Servers must decide which types of requests to accept as early data. Many deployments disable 0-RTT entirely for APIs and restrict it to static content retrieval.

The Encrypted Client Hello (ECH) Extension

TLS 1.3’s remaining metadata exposure is the Server Name Indication (SNI) in the ClientHello, which reveals which hostname the client is connecting to. This information is sent in plaintext and is visible to network observers, enabling censorship and surveillance based on destination.

Encrypted Client Hello (ECH), formerly known as ESNI (Encrypted SNI), addresses this. The server publishes a public key in its DNS records (via HTTPS/SVCB records). The client encrypts the entire ClientHello (including SNI) to this key, sending only an “outer” ClientHello with a decoy SNI to the network. The server decrypts the inner ClientHello to determine the actual target.

ECH was still in draft as of early 2026, but Cloudflare, Firefox, and Chrome have deployed experimental support. When standardized, it will close the last major plaintext metadata leak in TLS 1.3 connections.

Cipher Suite Mechanics

TLS 1.3’s five cipher suites are:

In practice, approximately 60% of connections use AES-128-GCM, 30% use AES-256-GCM, and 10% use ChaCha20-Poly1305, according to Cloudflare’s 2025 TLS telemetry. ChaCha20-Poly1305 is preferred on devices without AES hardware acceleration (primarily older ARM processors), where it outperforms AES-GCM by 3-5x in software implementations.

All five suites are AEAD constructions. The hash algorithm is used for HKDF key derivation and the Finished HMAC, not for record-layer encryption. The key exchange algorithm (ECDHE or FFDHE) is negotiated separately via the supported_groups extension.

Record Layer

After the handshake, application data is transmitted in TLS records. Each record is encrypted with the current traffic key and a per-record nonce constructed from a 64-bit sequence number XORed with a per-connection IV derived during key derivation.

The record format:

ContentType (1 byte, always 0x17 = application_data)
Legacy Version (2 bytes, always 0x0303 for compatibility)
Length (2 bytes)
Encrypted Fragment:
    Plaintext content
    ContentType (real type: handshake, application_data, alert)
    Padding (optional, variable length zeros)
[AEAD authentication tag]

The real content type is encrypted inside the record, hidden from observers. An eavesdropper sees only application_data as the content type for every record, whether it contains handshake messages, application data, or alerts. The optional padding allows implementations to obscure the true length of the plaintext, mitigating traffic analysis based on message sizes.

Post-Quantum Considerations

TLS 1.3’s reliance on ECDHE key exchange means that recorded sessions are vulnerable to future quantum computers capable of solving the elliptic curve discrete logarithm problem. A sufficiently powerful quantum computer running Shor’s algorithm could retroactively decrypt recorded TLS 1.3 sessions if it recovers the ephemeral DH shared secret.

This is the “harvest now, decrypt later” threat. Nation-state actors are believed to be recording encrypted traffic at scale for future quantum decryption.

The response is hybrid key exchange – combining classical ECDHE with a post-quantum key encapsulation mechanism. Chrome and Cloudflare began deploying X25519Kyber768 hybrid key exchange in 2024, combining x25519 (classical) with ML-KEM-768 (post-quantum, formerly known as CRYSTALS-Kyber). The hybrid approach ensures that security degrades gracefully: even if the post-quantum algorithm is broken, the classical ECDHE component maintains current security levels.

As of early 2026, approximately 15% of TLS 1.3 connections to major CDNs use hybrid post-quantum key exchange, a percentage that is growing monthly as browser and server support expands.

Implementation Pitfalls

The TLS 1.3 specification is precise, but implementations diverge in ways that affect security.

Certificate validation. The protocol is only as secure as the certificate validation logic. Improper hostname verification, missing revocation checks, and failure to validate the certificate chain have caused vulnerabilities in implementations from Apple (goto fail, 2014), GnuTLS (2014), and numerous smaller libraries.

Random number generation. The security of ephemeral key exchange depends entirely on the quality of the random number generator used to produce ephemeral keys. The Debian OpenSSL bug (2008) reduced the effective randomness to 15 bits, making keys trivially guessable for two years before discovery. Cryptographic random number generation is foundational.

Side channels. Even with AEAD-only cipher suites, implementation-level side channels remain. AES-GCM implementations without constant-time guarantees can leak key material through timing variations. Implementations should use hardware AES-NI instructions or verified constant-time software implementations.

Session ticket management. TLS 1.3 session tickets, used for 0-RTT resumption, must be protected with the same rigor as long-term key material. If session ticket encryption keys are shared across servers in a load-balanced cluster and one server is compromised, all resumed sessions across the cluster are exposed.

TLS 1.3 in the Stealth Cloud Architecture

Stealth Cloud’s edge infrastructure runs on Cloudflare Workers, which terminate TLS 1.3 connections at Cloudflare’s edge network – over 300 points of presence globally. Every API call to api.stealthcloud.ai completes the TLS 1.3 handshake at the nearest edge node, typically within 5-15ms.

But TLS 1.3 alone is insufficient for zero-knowledge architecture. TLS protects data in transit. It does not protect data from the server. Once the TLS connection terminates, the server can read the plaintext. This is why Stealth Cloud implements end-to-end encryption as a separate layer on top of TLS: the client encrypts data with AES-256-GCM using keys that the server never possesses, and the encrypted payload traverses the TLS tunnel.

The Stealth Cloud Perspective

TLS 1.3 represents the best the industry has achieved for transport security. Its mandatory forward secrecy, AEAD-only cipher suites, and encrypted handshake metadata set a standard that prior versions never approached. The reduction from two round trips to one (and optionally zero) made security faster than insecurity – removing the last performance excuse for unencrypted connections.

Yet TLS 1.3 solves only one layer of the problem. It protects the pipe. It does not protect the data from the endpoints. A TLS connection to a server that logs your queries, profiles your behavior, and sells your metadata is an encrypted pipe to a surveillance machine.

Stealth Cloud treats TLS 1.3 as necessary infrastructure – the minimum viable transport security. The actual privacy guarantees come from the layers above: client-side encryption with keys the server cannot access, cryptographic shredding of session material, and a zero-knowledge architecture where the server is designed, from the ground up, to be unable to read what it transmits.

The handshake that protects the internet is a beginning. Not an end.