HTTPS encrypts the content of your web traffic. DNS-over-HTTPS encrypts your DNS queries. But there’s a gap between the two — a moment during every HTTPS connection where the domain name you’re visiting is transmitted in the clear, visible to anyone watching the network. That gap is the Server Name Indication (SNI) field in the TLS handshake, and Encrypted Client Hello (ECH) is the protocol designed to close it.
The Last Privacy Gap
When your browser connects to https://example.com, the TLS handshake happens before any encrypted data flows. During this handshake, the browser sends a ClientHello message that includes the SNI — the domain name the browser wants to connect to.
Why does this exist? Because a single IP address often hosts hundreds or thousands of websites (shared hosting, CDNs). The server needs to know which domain the client wants before it can select the right TLS certificate and establish encryption. The SNI tells it which certificate to use.
The problem: the ClientHello is sent in plaintext. Even with HTTPS and encrypted DNS, a network observer — your ISP, a coffee shop router, a government firewall — can see exactly which domain you’re visiting by inspecting the SNI field. They can’t see what you’re doing on the site, but they know you’re visiting it.
This isn’t theoretical. Deep packet inspection (DPI) equipment routinely reads SNI fields for:
- Censorship: Countries including China, Iran, and Russia use SNI inspection to block access to specific domains
- Corporate surveillance: Enterprise firewalls log SNI data for compliance and monitoring
- ISP tracking: Internet providers can build browsing profiles from SNI data even when DNS is encrypted
Encrypted DNS (DoH, DoT) solved half the problem. ECH solves the other half.
How ECH Works
ECH encrypts the sensitive parts of the ClientHello message using a public key that the client obtains before the TLS handshake begins. Here’s the mechanism:
Key Distribution via DNS
The server publishes its ECH public key in a DNS HTTPS record (more on this record type in the next chapter). When the client resolves the domain, it receives the ECH configuration alongside the IP address:
example.com. IN HTTPS 1 . alpn="h2,h3" ech="AEX+DQBBq..."
The ech parameter contains the server’s public key, encoded in a format defined by the ECH specification.
The Split ClientHello
With ECH, the ClientHello is split into two parts:
- ClientHelloOuter — sent in plaintext, contains a cover SNI (typically the CDN’s domain, like
cloudflare-ech.com) and the encrypted inner hello - ClientHelloInner — encrypted with the server’s ECH public key, contains the real SNI (
example.com) and other sensitive extensions
A network observer sees only the outer ClientHello. They see the client connecting to cloudflare-ech.com — but they can’t tell which specific site behind Cloudflare is being accessed. Since major CDNs host millions of domains, the SNI is effectively hidden in the crowd.
The Handshake Flow
- Client resolves
example.comand receives the HTTPS record with ECH keys - Client constructs ClientHelloInner with the real SNI (
example.com) - Client encrypts it with the ECH public key
- Client sends ClientHelloOuter with cover SNI (
cloudflare-ech.com) + encrypted blob - Server (the CDN edge) decrypts the inner hello using its private key
- Server identifies the real target domain and completes the TLS handshake
- All subsequent traffic is encrypted as normal
If the ECH keys are stale or the server doesn’t support ECH, the server can send a retry configuration with fresh keys, and the client retries. This graceful degradation prevents hard failures.
GREASE and Trial Decryption
To prevent ossification (network middleboxes learning to block ECH), the TLS working group introduced GREASE (Generate Random Extensions And Sustain Extensibility) for ECH. Clients occasionally send fake ECH extensions even when not using ECH, so middleboxes can’t distinguish real ECH from noise.
Servers may also need to perform trial decryption — attempting to decrypt the inner hello to determine if ECH is being used, since the outer ClientHello looks similar whether ECH is real or GREASEd.
Current Deployment Status
ECH has moved from specification to real-world deployment, though it’s still early:
Cloudflare enabled ECH support across its network in 2023, making it available to any site using Cloudflare as a CDN. Since Cloudflare handles a significant portion of the web’s traffic, this was a major step.
Firefox has supported ECH since version 118 (late 2023), enabled by default when the DNS resolver returns ECH keys via HTTPS records.
Chrome has been gradually rolling out ECH support, with it available behind flags and increasingly enabled by default in newer versions.
Safari and other browsers have been slower to adopt, though Apple has signaled interest in the privacy benefits.
Obstacles to Adoption
ECH deployment faces several challenges:
Enterprise resistance. Corporate security teams rely on SNI inspection for threat detection, compliance logging, and data loss prevention. ECH blinds these tools. Enterprise environments may block ECH at the network level or deploy managed root certificates to maintain visibility.
DNS dependency. ECH keys are distributed via DNS HTTPS records. If DNS resolution is compromised (no DNSSEC, no encrypted DNS), an attacker could strip the ECH keys from DNS responses and force a fallback to plaintext SNI. ECH’s privacy guarantees depend on secure DNS resolution.
CDN concentration. ECH’s privacy model works best when many sites share the same CDN infrastructure. If example.com is the only site behind a particular IP address, encrypting the SNI doesn’t help — the IP itself identifies the destination. ECH’s effectiveness scales with CDN adoption.
Government pushback. Countries that use SNI-based censorship have strong incentives to block ECH. Russia has already begun blocking ECH-enabled connections. China’s Great Firewall may follow. This creates an arms race between privacy technology and state-level network control.
Implications for DNS and CDNs
ECH tightens the coupling between DNS and TLS in important ways:
DNS becomes a key distribution channel. ECH keys in HTTPS records mean that DNS isn’t just resolving names — it’s distributing cryptographic material. This elevates the security requirements for DNS resolution. If an attacker can tamper with DNS responses, they can strip ECH support.
DNSSEC becomes critical. Without DNSSEC, there’s no way to verify that the ECH keys received via DNS are authentic. An on-path attacker could replace the HTTPS record with one that omits ECH, silently downgrading the connection. DNSSEC-signed HTTPS records close this attack vector.
CDNs gain more power. ECH’s privacy model relies on CDNs as privacy shields — the cover SNI points to the CDN, not the origin. This further centralizes the web’s architecture around major CDN providers. Whether this tradeoff (more privacy, more centralization) is net positive is debatable.
Key rotation complexity. ECH keys need to be rotated periodically (compromised keys would allow retroactive decryption of SNI data). Key rotation happens through DNS — updating the HTTPS record with new keys. DNS caching (TTL) creates a window where clients may use stale keys, requiring servers to support multiple key versions simultaneously.
Censorship Resistance
ECH has significant implications for internet freedom:
In a world with ECH fully deployed, a censor’s options narrow considerably. They can block entire CDN IP ranges (collateral damage: millions of legitimate sites go down), attempt to block the ECH extension itself (detectable via GREASE), or block encrypted DNS to prevent ECH key distribution.
Each option has costs. Blocking Cloudflare’s IP ranges means blocking a substantial portion of the internet. Blocking ECH extensions is an arms race that protocol designers are actively preparing for. Blocking encrypted DNS pushes users toward VPNs and other circumvention tools.
ECH doesn’t make censorship impossible. But it raises the cost substantially — from “inspect one header field” to “block entire infrastructure providers.” That cost increase matters in practice, even if it doesn’t eliminate censorship entirely.
The Bigger Picture
ECH represents the final piece of the encrypted web stack:
| Layer | Encryption | Protocol |
|---|---|---|
| DNS queries | ✅ Encrypted | DoH / DoT / DoQ |
| TLS handshake (SNI) | ✅ Encrypted | ECH |
| HTTP content | ✅ Encrypted | TLS 1.3 |
With all three layers encrypted, a passive network observer learns only that a client is connecting to a CDN — not which site, not what content, not what they’re doing. Active attackers face DNSSEC validation, certificate transparency logs, and ECH’s retry mechanisms.
This doesn’t mean perfect privacy. Traffic analysis, timing attacks, and server-side logging remain. But the network-level visibility that ISPs and governments have relied on for decades is disappearing. DNS, once the weakest link in web privacy, is becoming part of the solution.