Encrypted Client Hello (ECH): Privacy-First TLS at CDN Edge

Every TLS connection begins with a handshake that leaks a critical piece of metadata: the Server Name Indication (SNI). Before encryption is established, the client announces in plaintext which hostname it wants to connect to. For CDN providers terminating TLS at edge nodes serving thousands of domains behind shared IP addresses, this means every network observer between the user and the CDN knows exactly which website the user is accessing—even though the page content is encrypted.

Encrypted Client Hello (ECH), the successor to the abandoned Encrypted SNI (ESNI) proposal, solves this by encrypting the sensitive portion of the TLS ClientHello before it leaves the client. This article examines how ECH works at the protocol level, why CDN providers are the natural deployment vehicle, the operational challenges of ECH key management at global scale, and the privacy implications for CDN-delivered traffic.

The SNI Privacy Problem

TLS 1.3 encrypts nearly everything after the ClientHello. The certificate, the negotiated parameters, and all application data are protected. But the ClientHello itself contains the SNI extension in plaintext, and TLS requires this because the server needs to know which certificate to present before it can establish encryption.

This creates a paradox: the most sensitive metadata (which website the user is visiting) is the one thing TLS cannot protect. Network-level observers exploit this leak in several ways:

• Corporate firewalls inspect SNI to enforce web access policies without deploying TLS interception proxies
• ISP-level censorship systems block connections based on SNI matching against domain blacklists
• Passive surveillance builds browsing profiles by correlating SNI values with source IP addresses
• Network-based ad targeting uses SNI data to categorize user interests

The SNI leak is particularly problematic for CDN-delivered content because a single CDN IP address serves many domains. Without SNI, an observer knows only that the user connected to a CDN. With SNI, they know exactly which of the CDN’s millions of hosted sites the user visited.

How ECH Encrypts the ClientHello

ECH introduces a split ClientHello architecture. The TLS ClientHello is divided into an outer message (sent in plaintext) and an inner message (encrypted with HPKE). The inner ClientHello contains the real connection parameters including the actual SNI, while the outer ClientHello contains a cover SNI and the encrypted inner message as an extension.

ECHConfig Distribution via DNS

Clients obtain the ECH public key (ECHConfig) from DNS HTTPS resource records. When a client resolves a domain using DNS over HTTPS (DoH) or DNS over TLS (DoT), it receives the HTTPS record containing the ECHConfig alongside the A/AAAA records. The ECHConfig specifies the HPKE key encapsulation mechanism, the public key, and the maximum inner ClientHello name length.

# DNS HTTPS record with ECHConfig
example.com. 300 IN HTTPS 1 . (
    alpn="h2,h3"
    ech="AEX+DQBBuwAgACA..."
)

# ECHConfig structure (decoded):
# version: 0xfe0d
# config_id: 0x41
# kem_id: DHKEM(X25519)
# public_key: [32 bytes]
# cipher_suites: [AES-128-GCM, SHA-256]
# maximum_name_length: 64
# public_name: "cloudflare-ech.com"

The Split Mode: Why CDNs Are Essential

ECH defines a “split mode” where a client-facing server decrypts the outer ClientHello and a backend server processes the inner ClientHello. In CDN deployments, the edge node acts as both: it receives the outer ClientHello, decrypts the ECH extension to reveal the inner ClientHello with the real SNI, selects the appropriate certificate, and completes the handshake.

The critical insight is that ECH’s privacy depends on the anonymity set—the number of distinct domains sharing the same outer SNI. If a CDN edge IP serves only two domains, an observer who blocks one and watches for connection failures can trivially determine which site the user visited. CDN providers hosting millions of domains behind shared edge infrastructure provide the massive anonymity sets that make ECH meaningful.

CDN Edge Implementation

Key Management at Global Scale

ECH key management at CDN scale is substantially more complex than standard TLS certificate management. The ECHConfig private key must be available at every edge PoP worldwide, rotated regularly (recommended every 24 hours), and published to DNS before the previous key’s validity period expires. The DNS TTL for HTTPS records must be shorter than the key rotation period to ensure clients always have valid keys.

This creates a coordination challenge: the new ECHConfig must be published to DNS, propagated through DNS caches, and the corresponding private key deployed to all edge nodes before the old key is retired. During the transition window, edge nodes must accept both old and new keys. CDN operators implement this with a key overlap period (typically 2 to 4 times the DNS TTL) where both keys are active.

Retry Mechanism and Graceful Degradation

When ECH decryption fails (stale key, corrupted ECHConfig, or incompatible parameters), the edge server completes the handshake using the outer ClientHello’s cover SNI. This results in a connection to the CDN’s cover site, not the intended destination. The server includes the current ECHConfig in the retry_configs extension of the EncryptedExtensions message, allowing the client to retry with updated keys.

This retry adds one complete TLS handshake of latency (1-RTT with TLS 1.3). At CDN scale, even a small retry rate generates significant additional connection overhead. CDN operators track ECH retry rates as a key operational metric, targeting less than 0.1% retries across the fleet.

GREASE ECH for Censorship Resistance

To prevent network middleboxes from blocking connections that use ECH (by detecting the encrypted_client_hello extension), TLS implementations use GREASE (Generate Random Extensions And Sustain Extensibility). Clients that do not have an ECHConfig for a domain still send a synthetic encrypted_client_hello extension with random data. This ensures that middleboxes cannot distinguish ECH-encrypted connections from non-ECH connections based on extension presence alone.

CDN providers configure their edge servers to ignore unrecognized ECH extensions (GREASE values) without disrupting the connection. This creates plausible deniability at the protocol level: even if a censor blocks all connections with the encrypted_client_hello extension, they would block the substantial percentage of normal TLS connections that include GREASE ECH data.

Performance Impact at CDN Edge

ECH adds cryptographic overhead to the TLS handshake that is measurable but operationally manageable at CDN scale.

The HPKE decryption of the inner ClientHello adds approximately 0.1 to 0.2 milliseconds per handshake on hardware with AVX2 acceleration. The inner ClientHello is typically 200 to 400 bytes larger than a standard ClientHello due to the HPKE overhead, increasing the initial packet size but staying within a single TCP segment on most connections.

The more significant performance consideration is the interaction between ECH and TLS session resumption. Pre-shared keys (PSK) for session resumption are bound to the inner ClientHello. If a client presents a PSK in the outer ClientHello but the corresponding session was established with an inner SNI for a different domain, the resumption fails and falls back to a full handshake. CDN operators must carefully manage PSK binding to avoid unexpected resumption failures that increase handshake latency.

HTTP/3 and QUIC Considerations

ECH for HTTP/3 (QUIC) presents additional complexity. QUIC’s initial handshake packets use a different encapsulation than TLS-over-TCP, and the SNI appears in the QUIC CRYPTO frame rather than a TCP stream. The ECH specification accounts for QUIC integration, but CDN operators must ensure their QUIC implementation supports ECH at the QUIC transport layer, not just the embedded TLS layer.

QUIC’s 0-RTT connection resumption interacts with ECH in complex ways. A 0-RTT QUIC connection attempt with ECH requires the client to have both a valid PSK and a current ECHConfig. If either is stale, the connection falls back to 1-RTT, adding latency. CDN operators deploying both QUIC and ECH should expect a modest increase in connection establishment time during ECH key rotation windows.

Privacy Analysis and Limitations

ECH provides strong protection against passive network observers who cannot see DNS queries. However, several limitations affect the practical privacy guarantee:

DNS dependency: If the DNS query for the ECHConfig is not encrypted (using DoH or DoT), the observer learns the target domain from DNS before the ECH-protected TLS connection begins. ECH’s privacy guarantee is only as strong as the DNS privacy layer beneath it.

Traffic analysis: Even with ECH, network observers can use traffic analysis (packet sizes, timing patterns, connection duration) to probabilistically identify which site a user visits. CDN operators mitigate this with traffic padding and connection multiplexing, but traffic analysis remains a theoretical weakness.

Active attackers: An active attacker who controls the network can block ECH connections entirely, forcing clients to fall back to non-ECH TLS (which exposes the SNI). GREASE ECH mitigates this by making ECH blocking costly (it would break many non-ECH connections), but a determined censor could still selectively block ECH.

Small anonymity sets: If only a few domains on a CDN edge IP enable ECH while the majority do not, the privacy set is small. CDN providers should enable ECH by default for all domains to maximize the anonymity set.

ECH represents one layer in a privacy stack that includes OHTTP, DoH, and post-quantum cryptography. Together, these protocols transform CDN edge connections from privacy-leaking to privacy-preserving, though each addresses a different attack surface. CDN providers deploying ECH should communicate clearly about what ECH protects (SNI from network observers) and what it does not (client IP from the CDN itself).