Handshake Encryption: Endgame (an ECH update)

Encrypted ClientHello Moves Toward Real-World Deployment

Cloudflare has begun initial deployment of TLS Encrypted ClientHello (ECH), the IETF draft standard designed to encrypt the final remaining plaintext metadata in the TLS handshake. The rollout currently covers selected free zones in specific geographic regions, with plans to expand gradually while monitoring for failures.

ECH addresses a privacy gap that TLS 1.3 left open: the ClientHello message, including the target server name, is still visible in plaintext on the wire. Even with encrypted application traffic, an on-path observer can see which services a user connects to—information that, accumulated over time, can uniquely identify users based on their browsing patterns. ECH encrypts the ClientHello so that sensitive parameters like the service name are unintelligible to network observers.

How ECH Works

The mechanism is conceptually straightforward. Clients encrypt the ClientHello using a public key obtained via DNS lookup of the HTTPS resource record, which advertises the server's ECH capabilities. The destination server decrypts the message using the corresponding private key. This complements DNS-over-HTTPS (DoH): DoH hides DNS queries from observers, while ECH hides the TLS handshake parameters that would otherwise reveal which server a client is contacting.

There is, however, a critical distinction between the two protocols. A DoH recursive resolver is open—it will answer queries for any domain. An ECH client-facing server is closed, meaning it only terminates connections for a fixed set of authorized domains, known as the anonymity set. This set is public information; anyone can query DNS to determine which domains share a client-facing server.

This closed-set design has an important consequence: ECH cannot be used for domain fronting. A client that connects to a server using an authorized name from the anonymity set cannot then interact with a different domain within that same TLS connection. Requests for origins not matching the connection's domain will fail.

A Stronger Threat Model

Standard TLS analysis typically assumes a Dolev-Yao attacker who can read, modify, and delete network packets. ECH requires a stronger model: the attacker should not be able to determine which server in a known anonymity set a client is connecting to. Even an active attacker who can replay ClientHello messages or extract and reuse the ECH extension should gain no more advantage than random guessing.

Several specific attacks motivated design choices. An attacker might replay a captured ClientHello and observe the server's response; ECH prevents this by ensuring server certificates can only be decrypted by the intended client or client-facing server. An attacker might also attempt to masquerade as the server and observe whether a client behaves differently in response to forged messages; ECH blocks active injection without access to the private ECH key. Passive traffic analysis of packet sizes and timing remains an open problem, as it does for TLS generally.

To validate these properties, Cloudflare is working with external researchers on a formal analysis of the ECH design. The analysis targets two security goals: first, that ECH does not weaken the security of TLS without ECH; second, that connections to any host in a client-facing server's anonymity set are indistinguishable from connections to any other host in that set.

Deployment Concerns and GREASE

Historical experience with TLS 1.3 showed that middleboxes and other network software sometimes misbehave when confronted with protocol changes, a phenomenon known as ossification. ECH faces a similar risk of exposing or introducing such bugs. To mitigate this, ECH supports a GREASE variant requiring all ECH-capable clients to produce syntactically equivalent ClientHello messages—whether they are sending real ECH or a randomized placeholder when no ECH configuration is available.

This syntactic equivalence aims to prevent benign network bugs from distinguishing between real and fake ECH. Passive attackers cannot tell the difference, though an active observer can: comparing a ClientHello with the contents of DNS will reveal whether the ECH extension matches what is advertised. The resulting information, however, is not particularly sensitive—whether a client and server support ECH is assumed to be public knowledge. GREASE primarily smooths deployment against accidental network interference.

A more significant concern is for networks like enterprises and schools that rely on plaintext TLS metadata for filtering and parental controls. GREASE (or fake) ECH messages are semantically different from real ones, which could break these practices. Several potential solutions exist, with the most promising centered on DNS discovery: if clients can securely discover encrypted recursive resolvers capable of filtering, TLS-layer filtering may become entirely unnecessary. Canary domains offer an alternative approach but carry uncertainty about potential abuse to disable ECH. Cloudflare indicates it is seeking collaboration with browser vendors, network operators, and other stakeholders to find a deployment model that balances user privacy with legitimate network management needs.

Status and Next Steps

As ECH expansion proceeds, Cloudflare's stated goal is to work with the IETF's TLS working group to update the specification based on deployment experience, with the aim of making the protocol safe, secure, usable, and ultimately deployable at Internet scale. ECH is positioned as one component in a broader connection privacy strategy, alongside efforts to address other vectors where connection metadata leaks.