When you’re trying to hide, the last thing you want is to draw attention to yourself. That was the philosophy behind the design of Encrypted Client Hello (ECH), a new technology that helps close a 20-year-old privacy leak in the Internet’s design [1]. ECH encrypts the name of the website you’re visiting, making connections to different websites look similar to network observers. The ECH specification captures this in its primary design criterion: “do not stick out” [6]. As ECH moved from specification to real-world deployment in 2024, that principle faced its first major test. The story of ECH’s rollout reveals how difficult it is to achieve invisibility through uniformity in the real world.
From Theory to Practice
Hypertext Transfer Protocol Secure (HTTPS) already encrypts the content of your web traffic, but it leaves one critical piece of metadata exposed: the Server Name Indication (SNI), which reveals exactly which website you’re connecting to. SNI was originally invented so that website operators could host multiple sites on the same server, but doing so made the website’s hostname public. ECH was designed to close this gap by encrypting the SNI and other sensitive connection-related information. Once ECH is widely deployed, all encrypted connections become functionally indistinguishable so that no single connection stands out.
This uniformity is what enables the privacy benefits. With ubiquitous ECH, Internet providers can’t easily build profiles of which sites you visit, advertisers lose a key tracking vector, and corporate networks can’t monitor employee browsing patterns as easily. When no single connection stands out, the result is privacy through indistinguishability. This promise of broad privacy protection drove worldwide interest in ECH, but ECH’s ability to resist censorship (an inherent consequence of hiding destinations) drew the attention of those seeking to limit online access.
Implementing ECH across the entire Internet, where millions of devices and numerous networks need to collaborate while dealing with active censorship, presents its own set of challenges. To fully grasp these challenges, it’s important to understand how ECH establishes uniformity in the first place.
GREASE: Making Encrypted Connections Look Alike
To achieve uniformity, ECH relies on a technique called GREASE (Generate Random Extensions And Sustain Extensibility, a cheeky acronym coined by TLS engineers) [2][12]. The idea is simple: even when a browser doesn’t have an ECH configuration for a site, it still sends what appears to be an ECH extension, filled with random data. This way, every connection looks the same from the outside. An observer watching the handshake can’t tell whether the browser successfully encrypted the destination or just sent fake ECH data because the message format is always the same. Or at least that’s the theory.
GREASE’s primary purpose is to prevent compatibility bugs and ensure that network infrastructure doesn’t fail when it encounters unfamiliar protocol extensions. GREASE also provides a useful side effect: it stops casual fingerprinting by passive observers. In theory, if all browsers adopted ECH (or at least sent the dummy GREASE signals), censors and filters would see no apparent difference between a connection that used real ECH and one that didn’t. The ECH specification emphasizes that GREASE helps ensure ECH connections blend in with regular traffic, making your web browsing on sites that don’t support ECH look similar to your web browsing on sites that do [6].
GREASE serves its intended purpose: to make Encrypted ClientHello (ECH) syntax widespread at the protocol level. However, as described below, achieving uniformity in the protocol does not eliminate all identifiable patterns. As ECH transitioned from specification to real-world deployment, these remaining patterns became problematic.
By the end of 2024, ECH was turned on by default across millions of websites served by Cloudflare. Major browsers were also supporting the rollout: Mozilla enabled ECH by default in Firefox 119, which was released to all users in October 2023 [10], and in September of that year, Google Chrome added ECH support in version 117.
But then came the response. If ECH’s design goal was not to stand out, its initial deployment ironically did attract attention, especially from well-known censorial governments monitoring user traffic. The most prominent example came from Russia, where in November 2024, the internet watchdog (Roskomnadzor) moved to block thousands of websites using ECH [4].
In a public statement, Roskomnadzor described ECH bluntly as “a way to bypass restrictions on access to information that’s banned in Russia. Using it goes against Russian law.” [4] The government urged domestic website owners to stop using Cloudflare’s services if it meant having ECH turned on, even recommending they switch to Russian CDN providers [4]. This was a remarkable reaction: a new privacy feature was deemed so threatening that they moved to actively block it just weeks after it rolled out by default.
Case Study: How Russia Blocked ECH
To understand what was exploited, here’s a quick refresher on how ECH works in practice. When your browser makes an ECH connection, the TLS handshake contains two domain names: an outer SNI (Server Name Indication) that’s visible to network observers, and an inner SNI that’s encrypted within the ECH extension. The inner SNI contains the actual destination you’re trying to reach, while the outer SNI can technically be any value. This dual-layer design is what enables ECH’s privacy: observers see only the generic outer address, not the specific site you’re visiting.
Russia’s action exploited a weakness in that outer layer. In Cloudflare’s deployment, browsers connecting via ECH consistently used the same outer SNI value for all connections: cloudflare-ech.com (the public_name specified in Cloudflare’s ECH configuration) [3][5]. The ECH specification technically allows any name in the outer SNI, but browsers chose to use this consistent value for a deployment quirk we’ll examine shortly. Roskomnadzor’s filters exploited this pattern, looking for that specific outer SNI paired with an ECH extension. If both appeared, the connection was dropped.
Website owners who relied on Cloudflare suddenly found their sites unreachable for users in Russia unless they disabled ECH [4]. This incident highlighted a core challenge of Internet engineering: when only one big provider offers ECH, censors can single out that provider’s traffic without too much collateral damage. ECH deployments using other, less common public names would, in theory, be harder to detect at scale [5]. Ironically, Cloudflare’s enormous network (a strength, typically) became a weakness in the face of targeted censorship.
The Paradox of Privacy Adoption: Standing Out to Disappear
ECH’s rollout illustrates a classic paradox in the world of privacy tech: to disappear into the background eventually, a new technology first has to stick its neck out. A protocol like ECH is most powerful when it’s ubiquitous, when every connection is protected, leaving no outliers to examine. But to get to ubiquity, it has to start somewhere, and the early adopters inevitably stand out simply by being early. It’s a coordination problem: someone has to go first, but being first makes you conspicuous. And if you’re a global company, being conspicuous can put you in a challenging position.
GREASE helps solve part of this problem. By getting browsers to send ECH-shaped connections even for sites without ECH turned on, GREASE made the syntax ubiquitous. Censors could no longer block all ECH-shaped traffic without blocking entire browsers. This near ubiquity of GREASE gave cover for the percentage of actual ECH traffic to grow within this protected group.
But GREASE alone wasn’t enough to provide true uniformity in the initial roll-out. The problem wasn’t that ECH connections stood out from non-ECH connections (GREASE fixed that). The problem was that within the pool of ECH-shaped traffic, the concentration of connections using the same outer SNI (cloudflare-ech.com) created a targetable pattern. In practice, because Cloudflare was the only major provider using ECH, and all ECH connections using Cloudflare shared the same outer SNI (cloudflare-ech.com), censors could block ECH with a single filter rule. They would just have to look for that domain name in the outer SNI field and drop the connection. No sophisticated detection was needed.
Why ECH Traffic Stuck Out
Remember that deployment quirk mentioned earlier? Why did browsers choose to use the same outer SNI for all ECH connections? The answer lies in how ECH handles configuration updates.
In technical terms, ECH configurations are distributed via DNS, and the actual handshake that uses DNS happens over HTTPS. All this is a bit of an acronym soup (something standards bodies are infamous for), but in simpler terms, the browser first has to check the directory (DNS) to get the key to encrypt the hostname when connecting to the actual website securely (using HTTPS). This key is rotated regularly, and sometimes the browser doesn’t have the latest key when it tries to connect to the site.
When the key in the browser and the key on the server fall out of sync (say, a client has an outdated configuration), the ECH specification includes a recovery mechanism (called retry_configs) that lets the server send the latest ECH key [6]. This is very useful for browsers, letting them reconnect with the right key immediately without consulting DNS and not revealing your destination.
However, there is a constraint baked into this recovery mechanism that has caused some unexpected problems, and that has to do with how to trust an updated configuration that doesn’t come from DNS. Clients are only allowed to receive updates over a trusted channel. In this case, that means a connection in which the server presents a certificate valid for the “public name” of the ECH key [6]. This limitation presents a quandary for server website operators. Because a server that can’t decrypt an ECH extension doesn’t know if it’s looking at GREASE (fake ECH) or real ECH with a stale key, the only reliable signal for what “public name” the browser will accept is the outer SNI. For ECH servers, to reliably send updated keys, they need a hint from the client about which public_name to use if the key has expired.
This desynchronization problem isn’t theoretical. Stale configurations were common enough during deployment that, without the inline retry mechanism, too many connections would fail to roll out the change to the general population. So what was the solution? Browsers decided to put the public name into the outer SNI for ECH so the server would have a signal to provide the updated key with the right certificate. Now, every ECH connection will have an outer SNI that matches the public name of the service. But, given that there was only one large provider at the time, Cloudflare, with a single public name for ECH keys (“cloudflare-ech.com”), it became easy to target ECH traffic.
The design goal of “do not stick out” failed at multiple layers: not enough providers deploying ECH, and all connections from each provider using the same outer SNI. A technical constraint in the specification (trusted channels for updates) imposed a deployment constraint (public names must be used) that forced the deployment to violate ECH’s core principle (ECH should not stand out). All this is predicated on the fact that only a limited number of websites and providers have ECH enabled.
Work is underway to address this with a technical fix. A draft specification for “Authenticated ECH Config Distribution and Rotation” removes the requirement for a trusted channel and instead uses a digital signature [7]. The proposal enables servers to deliver cryptographically signed ECH configurations during the TLS handshake, allowing clients to authenticate and use updated configs regardless of which name appears in the outer SNI. Supporting signed configs would let clients (browsers) diversify the outer SNI values they use (making detection harder) while still allowing them to update ECH configurations in-band. By decoupling the public_name certificate requirement from config updates, future ECH deployments could achieve both reliability and better resistance to targeted blocking. The next post in this series explores the key distribution challenge and possible solutions.
Lessons Learned
The rollout of Encrypted Client Hello (ECH) highlights a fundamental challenge in deploying privacy technologies at scale. The main goal of ECH was to achieve invisibility through uniformity, meaning that every connection would appear identical. While the GREASE initiative successfully introduced uniformity at the protocol level by making ECH syntax widespread, this alone was not sufficient. Achieving true invisibility goes beyond mere technical correctness; it requires collaboration among service providers, careful attention to seemingly minor implementation details that can become identifying patterns, and an awareness of how certain design choices can create unwanted trade-offs between reliability and privacy.
Privacy technologies face a coordination problem that other technologies don’t. A new video codec can roll out gradually, provider by provider, without compromising anyone’s privacy. But a privacy protocol that only a few use can become a liability. The feature meant to hide you becomes the thing that identifies you. This dynamic isn’t unique to ECH; it’s a tension inherent to any privacy tool that relies on blending in with a crowd.
The motto “do not stick out” turns out to be harder than it sounds. It’s not enough to avoid sticking out at one layer. ECH needed to avoid sticking out at the protocol layer (GREASE handled that), at the deployment layer (too few providers), and at the configuration layer (too many connections using the same outer SNI). Deployment details that seem purely technical can become blocking opportunities when overlooked.
These are the lessons that make ECH’s eventual success possible. As more providers deploy ECH and proposed fixes like signed configuration distribution address the outer SNI constraint, the diversity that was missing in 2024 becomes attainable. The early stumbles weren’t failures; they were the necessary process of learning what “do not stick out” actually requires at every layer. ECH is becoming harder to block as adoption grows, and its specification is nearing final publication as RFC 9849. The path from standing out to blending in is now clearer for the next generation of privacy tools.
British Public Oppose Secret Surveillance Powers and Want Strong Protections for Encrypted Communications
CDT released nationally representative polling data revealing that a the British public are broadly concerned about the security, privacy, and free speech consequences of allowing law enforcement to access encrypted communications.
Changing Course to Get It Right: The Advisory Committee Reviews Its AI Evidence Rule
CDT is keeping a close eye on Proposed Federal Rule of Evidence 707, which would govern when AI-generated information can be admitted as evidence in federal court — and many state courts where the federal rules are routinely adopted — without a human expert to explain it.
