TL;DR: TLS encrypts the body of every connection but historically leaks the hostname in cleartext on the very first packet — the SNI field of the ClientHello. Encrypted Client Hello (ECH, RFC 9460) wraps that hostname inside an outer ClientHello, encrypted with a public key the server publishes via DNS. Network observers see TLS happening but not which specific site you’re visiting. Cloudflare turned it on for every proxied domain in September 2023; Firefox made it default in 2024. The pragmatic way to get ECH in 2026 is to put your origin behind Cloudflare.

What is it?

To understand ECH, you have to understand the leak it closes — and the leak is older than TLS 1.3 itself.

When a browser opens a TLS connection, the very first message it sends is the ClientHello. That message includes a field called Server Name Indication (SNI), which carries the hostname the client wants to reach — yourdomain.com, in plain ASCII, before any encryption has been negotiated.

SNI exists for a practical reason. Most production web servers host multiple sites on the same IP address. When the TCP connection lands, the server has no idea which of its hundreds of certs to present. SNI tells it. Without SNI, you couldn’t run name-based virtual hosting on TLS at all, and the modern shared-IP web couldn’t exist.

The cost is a privacy hole. Anyone sitting on the network path — your ISP, the corporate proxy on your office Wi-Fi, the censor at the country boundary, the snoop on the airport hotspot — can read the SNI of every TLS connection you make. They can’t read the content (that’s why TLS exists), but they can build a comprehensive log of which sites you visit. SNI metadata is exactly the metadata ad-tech, surveillance, and censorship infrastructure cares about.

Encrypted Client Hello (RFC 9460, standardised in 2024 after years of drafts) closes the hole. The mechanics:

  1. The server (or its CDN) generates an ECH config — a public key plus some metadata — and publishes it in a DNS HTTPS resource record alongside the domain.
  2. The client looks up the HTTPS RR before connecting, fetches the ECH public key, and uses it to encrypt the real ClientHello — real SNI, real ALPN, real everything — into an opaque blob.
  3. The client wraps that blob inside an outer ClientHello whose SNI is a generic, public name like cloudflare-ech.com (the name of the fronting host, not the actual site).
  4. The server decrypts the inner ClientHello, learns the real destination, and continues the handshake against the right cert.

To a network observer the only thing visible is “client connected to Cloudflare and did some TLS.” The specific site is encrypted.

Why does it matter?

For most sites, on most networks, ECH is “nice to have.” For users on networks that actively mine SNI metadata, it’s a meaningful privacy upgrade:

  • Corporate proxies routinely log and policy-enforce on SNI — blocking categories of sites by hostname, building employee browsing reports, feeding DLP systems. ECH makes those policies blind to the destination.
  • ISPs in several markets sell aggregated browsing metadata derived directly from SNI. ECH cuts off the data source.
  • Censoring governments block sites by SNI rather than IP, because IP blocks catch too many co-tenants on shared hosting. SNI-based blocking is the dominant mode of national-firewall censorship today; ECH is one of the few protocol-level countermeasures.
  • Public Wi-Fi operators snoop SNI for a mix of analytics and policy enforcement. ECH locks them out.

Adoption is still small. Cloudflare went GA on ECH for all proxied domains in September 2023, which instantly made hundreds of millions of sites ECH-capable on the server side. Firefox enabled ECH by default in 2024, on connections where the outer SNI is a known ECH-supporting host (Cloudflare today). Chrome ships it behind a flag as of April 2026; Safari is still adding support.

The tail of the web — self-hosted origins, smaller CDNs, on-prem load balancers — is mostly not on ECH yet. Being on it in 2026 is a genuine modernity signal.

Real-world analogy

Picture sending a physical letter through the postal system.

Without ECH, your envelope has the destination address printed on the outside. Anyone handling the envelope knows where you’re sending it, even if they can’t open it and read the letter. The post office, the carrier, the building manager — all of them see the address.

With ECH, the address itself is encrypted. The envelope still has to go somewhere to enter the postal network, so the outside reads “Cloudflare Sorting Facility, San Francisco.” Observers see you mailing something to the sorting facility. They don’t see which of the millions of letters that pass through that facility every day is yours, or where it’s ultimately bound.

The privacy guarantee is “lost in the crowd.” You’re not invisible — you’re indistinguishable from every other visitor to every other site that uses the same fronting host.

A short on the outer hostname

The crowd matters. ECH still requires some outer hostname for the underlying TCP connection and the outer ClientHello. That name is typically the CDN’s own ECH-fronting hostname — cloudflare-ech.com in Cloudflare’s case.

This means a network observer can still tell that you’re connecting to Cloudflare. The privacy gain is that they can’t tell which of the millions of sites behind Cloudflare you’re connecting to. As long as the anonymity set (the number of sites sharing the same outer SNI) is large, the observer’s per-connection information is essentially “you used the modern internet today.”

The corollary: ECH’s privacy is only as strong as the anonymity set it provides. A self-hosted ECH deployment with one site behind it gives you almost nothing — observers see “you connected to that-one-domain.com” via the outer SNI. The protocol works best on a shared fronting host with a large, diverse tenant base. This is why Cloudflare is the de facto deployment vehicle.

How WQI measures this

We grade ECH support as factor WEBQ-93 in the Privacy category.

Unlike most TLS factors, this one isn’t visible from a Worker-side TLS prober. ECH negotiation requires the DNS HTTPS record key, which Workers don’t naturally fetch as part of an HTTP request. So we read the result downstream: every page-load on the test connection runs through Cloudflare URL Scanner (a hosted Chrome instance with full DevTools), and we capture the securityDetails.encryptedClientHello flag from the Network event — Chrome’s authoritative record of what actually happened on the wire.

ResultWhat it means
Pass (100)ECH negotiated on the test connection.
Fail (0)ECH not used (default for the long tail of the web).

There’s no “warn” tier — ECH is a binary protocol fact. Either it was negotiated or it wasn’t.

What good looks like

Pass on WEBQ-93. For most operators in 2026, that means putting the domain behind Cloudflare and benefiting from their automatic ECH deployment. ECH is enabled by default for all proxied zones — no config required, no separate plan, no extra cost. If your domain is already on Cloudflare’s orange cloud and you’re failing this factor, something else is going on (see pitfalls below).

For most non-Cloudflare deployments, “good” today is “we know we can’t do this yet on our stack, and we have a plan to migrate when the toolchain catches up.” That’s a reasonable posture in 2026.

How to fix it (or not, depending on your stack)

Cloudflare-fronted domains. Already done. ECH ships on by default for proxied zones. If you’re not seeing pass, check that the zone is actually proxied (orange cloud, not grey) and that you don’t have a DNS HTTPS record overriding the auto-generated one.

Self-hosted origins. Native ECH requires both halves of the mechanism to be in place:

  1. Publishing side. A DNS HTTPS resource record (RR type 65, not the same as https:// URLs) on your domain that publishes the ECH config — public key, supported AEADs, fronting host. Most major DNS providers (Cloudflare, Route 53, NS1) now support HTTPS RR; some smaller ones still don’t.
  2. Termination side. A TLS terminator that knows how to decrypt the inner ClientHello using the published key. The state of support as of April 2026:
    • BoringSSL — supports ECH (Google’s own stack; what Chrome and Cloudflare use internally).
    • OpenSSL — the ECH branch (originally from defo.ie) is mature but hasn’t merged into mainline. OpenSSL 3.5 has some experimental support behind feature flags. Stable distros (Debian, RHEL, Ubuntu LTS) ship without it.
    • NGINX, Apache, HAProxy — none have native ECH in stable releases. NGINX has community modules; not production-grade.
    • Caddy — no ECH support yet.

The honest answer for most production self-hosted setups is: native ECH isn’t realistic in 2026. Either front the origin with Cloudflare or wait for the OpenSSL ECH branch to merge upstream and the distros to catch up — probably a 2027-2028 timeline.

Common pitfalls and open questions

  • ECH vs. ESNI. ESNI (“Encrypted SNI”) was an earlier draft approach with similar goals. It was deprecated when fundamental weaknesses were found (an active attacker could correlate the ESNI keyshare with the destination). ECH is the successor, with a redesigned outer/inner ClientHello structure. You may still see ESNI references in old blog posts and config docs — ignore them. The current standard is ECH.
  • Browser support is uneven. Firefox ships ECH default-on as of v118 (October 2023, expanded in 2024). Chrome ships it behind a flag (chrome://flags/#encrypted-client-hello) as of April 2026 — enabling-by-default has been on the team’s roadmap for over a year with no firm date. Safari has not shipped support yet but is reportedly working on it. Edge follows Chrome.
  • DNS HTTPS records are not universal. ECH needs the client to fetch the HTTPS RR before connecting. Some DNS resolvers strip unknown record types; some clients don’t query for them. The failure mode is graceful — the client falls back to an unencrypted ClientHello — but it’s a quiet failure that’s hard to detect.
  • Cloudflare’s outer SNI is cloudflare-ech.com. This is now a network-observable signal in its own right (“this user is using ECH on Cloudflare”). For anti-censorship use cases the outer SNI could itself be blocked, defeating ECH for that user. The arms-race continues.

Further reading