Every lock needs a key, but that key only works if it’s in the hands of the person who needs to use it. That’s the fundamental challenge facing encrypted DNS and Encrypted Client Hello (ECH). These protocols can protect your browsing from prying eyes, but only if you can first obtain the cryptographic configurations that make them work. In places like China, censors have figured out that you don’t need to break the encryption. You just need to block the key deliver
This is the third post in a series on ECH. The first post examined what ECH is and why it matters [1]. The second explored the challenges of rolling out ECH without drawing attention from censors [2]. This post focuses on a different vulnerability: the DNS-based censorship that can prevent ECH from ever getting started, using China’s Great Firewall as the primary example.
Something Strange in the DNS
DNS is the Internet’s phonebook: It translates text-based domain names into numerical IP addresses so your computer can reach the right website. Corrupt that phonebook and you control what people can access. Long before encrypted DNS was on the scene, censors recognized this vulnerability. China’s Great Firewall became notorious for DNS injection, swiftly returning fake IPs for blocked domains [4]. But encrypting DNS was supposed to fix that.
In early 2021, users on a GitHub thread began comparing notes [3]. Something strange was happening to their encrypted DNS connections inside China. The servers weren’t permanently blocked; they still responded to pings. But after making a DNS-over-HTTPS query, the connection would fail for a few minutes, then come back up. It took the community a while to piece together what was happening: the Great Firewall had found a new way to strangle encrypted DNS without outright blocking it.
The pattern that emerged was methodical. Plain, unencrypted DNS was still being poisoned as always (fake replies were injected faster than real ones, and wrong IPs were cached across the network). DNS-over-TLS (DoT) on port 853 (the port typically affiliated with DoT) was simply blocked outright, with connections never completing. But DNS-over-HTTPS (DoH) required something more clever. Because DoH hides DNS queries inside regular HTTPS traffic on port 443 (the default port for HTTPS traffic), mixed in with all web browsing, the firewall couldn’t just block the port without blocking everything. Instead, it appeared to identify DoH traffic through deep packet inspection or active probing, then temporarily blacklist the resolver’s IP after each query [3]. The result wasn’t a clean block; it was death by unreliability, because people often give up trying to access a website after a few seconds [10].
How did the firewall know it was looking at a DNS query inside HTTPS? Possibly via patterns like the DNS provider’s hostname in the Server Name Indication (SNI) we discussed in the previous post, or by actively probing suspected servers to see if they responded to DoH requests [3]. The exact method remains unclear, but the outcome was unmistakable: encrypted DNS protocols were being systematically degraded. A DoT connection couldn’t be established, and DoH connections became too flaky to use.
This degradation wasn’t subtle. Studies show that dozens of backbone networks in China inject forged DNS replies, and that even DNS traffic passing through China (not just originating there) can get intercepted, causing collateral damage internationally [4]. China also showed a willingness to blackhole entire IP ranges of popular DNS resolvers, such as Cloudflare’s 1.1.1.1[5] (a public DNS resolver that makes DNS queries faster and more secure).
The result: in heavily censored regions, the average user has no choice but to use the DNS provided by their ISP, which the government tightly controls. The Great Firewall has effectively forced users back to resolvers it can surveil and tamper with [3]. Merely encrypting a protocol doesn’t help if the regime simply blocks the protocol wholesale.
This brings us to ECH. Encrypted Client Hello is the latest tool in the privacy arsenal, encrypting the TLS handshake’s SNI (and related extensions) to close one of the few remaining privacy leaks in HTTPS: the plaintext hostname. With ECH, a network observer shouldn’t be able to tell which website is being visited by inspecting the TLS handshake. This has big implications for censorship circumvention, because many censors rely on SNI filtering (blocking connections to example.com by spotting that name in the handshake). ECH is meant to nullify that tactic.
But here’s the catch: ECH has a bootstrapping dependency. Before the client can encrypt its Client Hello, it needs to fetch the server’s ECH public key (the ECH config). And that key comes from DNS. Specifically, a DNS record (an HTTPS or SVCB record) associated with the domain [6]. In other words, ECH relies on DNS to get its key material. And as we’ve just seen, DNS (even encrypted DNS) is under the censor’s thumb in places like China.
This creates a catch-22. If DNS queries are blocked or tampered with, the genuine ECH config for the intended site never reaches the client. The Client Hello can’t be encrypted without it. At best, the connection falls back to a standard TLS handshake (exposing the SNI and allowing for censorship via traditional deep packet inspection); at worst, it fails entirely. ECH becomes unusable not because the algorithm is broken, but because the key never arrives.
A 2025 study on ECH in censorship confirmed this vulnerability [5]. In Iran and China, the authorities don’t bother trying to break ECH in transit algorithmically. They simply block the DNS routes needed to bootstrap it. The result is that ECH cannot be used “by default” in those countries at all [5]. Firefox and other browsers might support ECH, but they typically require DNS-over-HTTPS for the ECH config lookup. If that DNS query is censored or the DoH server is unreachable, ECH is effectively dead on arrival.
ECH faces a dual threat: Either its DNS bootstrap is sabotaged (China’s approach) or the handshake itself may be fingerprinted and blocked (Russia’s approach). Both vectors have already been demonstrated by large nation-state censors [5]. The “do not stick out” principle can fail at multiple layers.
Breaking the DNS Dependency
Can the key be delivered some other way? The challenge is that DNS currently serves two functions: distribution (i.e., where to find the config) and authentication (i.e., whether to trust that the config is correct). To break the DNS dependency, you need to solve both.
For distribution, there are alternatives. An origin server could publish its ECH config at a well-known HTTPS endpoint (/.well-known/origin-svcb) that clients or DNS infrastructure can fetch directly [9]. A server could deliver its config during the TLS handshake itself, piggybacking on the secure connection. Somebody could even distribute configs through CDNs or more exotic structures, such as Distributed Hash Tables (one of the key technologies behind bittorrent and peer-to-peer file sharing), or emerging systems paradigms like Key Transparency [11].
For authentication, the answer is to sign the configuration. A new draft presented at the Internet Engineering Task Force (IETF) proposes treating ECH configurations as cryptographically signed objects [8]. The domain owner signs the configuration, and clients can verify that signature regardless of where they obtained it. This approach is what makes alternative distribution channels trustworthy: The source doesn’t matter because the signature proves authenticity.
ECH, DoH, and others are powerful technologies, but their potential depends on how users discover and bootstrap these connections. Each cycle of this arms race tends to leave the Internet a bit more private and secure. Ten years ago, few imagined that DNS itself would be encrypted or that we’d have a way to hide TLS hostnames. Now, both of those are realities, and censors are playing catch-up.
Every lock needs a key, and every key needs to end up in the right hands. Right now, that delivery mechanism is the weak link. Exploring ways to fix it is the next step in improving privacy and censorship resistance with ECH.
Sources
[1] Sullivan, “Encrypted Client Hello: Closing the SNI Metadata Gap”, CDT Insights, October 2025 https://cdt.org/insights/encrypted-client-hello-closing-the-sni-metadata-gap/
[2] Sullivan, “Do Not Stick Out: The Dynamics of the ECH Rollout”, CDT Insights, November 2025 https://cdt.org/insights/do-not-stick-out-the-dynamics-of-the-ech-rollout/
[3] Dynamic blocking of DNS over HTTPS in China? · Issue #68 · net4people/bbs · GitHub https://github.com/net4people/bbs/issues/68
[4] The Great Firewall of China: A Digital Black Hole https://www.catchpoint.com/blog/great-firewall-of-china
[5] Encrypted Client Hello (ECH) in Censorship Circumvention https://www.petsymposium.org/foci/2025/foci-2025-0016.pdf
[6] Implementing TLS Encrypted Client Hello – Guardian Project https://guardianproject.info/2021/11/30/implementing-tls-encrypted-client-hello
[7] Great Firewall of China blocks encrypted SNI extension | Cryptography & Security Newsletter | Feisty Duck https://www.feistyduck.com/newsletter/issue_68_great_firewall_of_china_blocks_encrypted_sni_extension
[8] N. Sullivan, D. Jackson. draft-sullivan-tls-signed-ech-updates-01 – Authenticated ECH Config Distribution and Rotation https://datatracker.ietf.org/doc/draft-sullivan-tls-signed-ech-updates
[9] Farrell, Salz, & Schwartz, “A well-known URI for publishing service parameters”, Internet-Draft https://www.ietf.org/archive/id/draft-ietf-tls-wkech-11.html
[10] Nielsen, J. ”Usability Engineering” https://www.nngroup.com/articles/response-times-3-important-limits/
[11] Key Transparency group, IETF, https://datatracker.ietf.org/wg/keytrans/about