Encrypted Client Hello on a CDN hides which site a visitor is opening from anyone watching the wire, but only by blending that site into a crowd. Since RFC 9849 made ECH a standard in March 2026, the practical question for buyers is no longer whether it works. It is whose crowd you join, and who controls the DNS that carries the keys.
What Encrypted Client Hello actually hides
Every TLS connection opens with a ClientHello, and until now its server_name field told any observer the exact hostname. ECH splits that message in two. The real one, with the true hostname, is encrypted to a public key the provider publishes. An outer one travels in the clear and names something generic. On Cloudflare that outer name is cloudflare-ech.com; Vercel uses vercel-ech.com. An observer sees a visit to the CDN, not to your shop, clinic or newsroom.
That is the whole mechanism, and it explains the catch: the privacy is exactly as large as the set of sites sharing the outer name. A provider with millions of zones behind one name gives each of them real cover. A small edge with a handful of customers hides very little, because the outer name narrows the guess to a short list.
Why the keys live in DNS
The browser needs the provider's public key before it says hello, so the key has to arrive earlier, in DNS. The companion standard, RFC 9848, carries the ECH configuration in the ech parameter of HTTPS (SVCB) records. Two consequences follow. First, whoever runs your authoritative DNS must publish and rotate those records in step with the edge that holds the private key. That is why Vercel offers ECH only on domains using Vercel DNS, and why Cloudflare does it on zones it serves itself. Second, the lookup should be encrypted too: a plain-text DNS query for your hostname leaks what ECH was meant to hide, which is why Firefox ties ECH to DNS over HTTPS. Our guide to DNS for a CDN covers the record types involved.
Who offers it today
| Provider | ECH status (Nov 2026) | Condition |
|---|---|---|
| Cloudflare | Production; on by default for Free zones | Other plans switch it on in the dashboard, per Cloudflare's docs |
| Vercel | Production | Only for domains on Vercel DNS |
| Akamai, Fastly, CloudFront | No general-availability announcement found | Fastly engineers co-authored the RFC; watch the changelogs |
On the client side, recent Chrome, Edge and Firefox support it; Safari does not expose it. Visitors without support fall back to an ordinary handshake, so enabling ECH never breaks a page.
Where it bites: multi-CDN and corporate networks
A multi-CDN estate has a problem with no tidy answer yet. Each provider has its own outer name and keys, so the HTTPS record a resolver returns must match the CDN that DNS steering picked. Hand out one provider's ECH configuration while steering to another, and clients that try ECH get a retry or a plain handshake. Until steering platforms manage per-provider HTTPS records, most multi-CDN setups leave ECH off.
Corporate security teams feel it from the other side. Filtering proxies that block or route by SNI now see only the CDN's outer name, a point the CIS and Broadcom's support notes both make. Expect requests to decrypt or block the outer name, and agree a policy before your audience's IT departments do it for you.
Should you turn it on?
Yes, if you are already on a provider that offers it, you serve one CDN, and your audience includes people whose browsing deserves cover. It costs nothing and fails safe. No, or not yet, if you run several CDNs behind DNS steering, or if your users sit behind corporate filters you also have to satisfy. It is the same TLS-at-the-edge trade we described for post-quantum key exchange: worth having when the provider carries it, not a reason to switch providers on its own.
Want to know whether ECH fits your edge and DNS set-up? The assessment checks it against your traffic.