Even ECH-capable browsers frequently GREASE rather than attempt real ECH, with Firefox/138 succeeding only 50% of the time (164/325), Chrome/136 only 25% (42/167), and Chrome Mobile/136 only 24% (29/121). Firefox/139 performed better at 83% real ECH success (351/423), suggesting browser DNS handling of HTTPS RRs remains a significant barrier to ECH efficacy. GREASE sends a fake ECH extension that does not hide the inner SNI, so it provides no censorship resistance despite making the client appear ECH-aware.

Apple iOS devices showed zero ECH successes across all tested versions from iOS 9.1 through iOS 18.5 (totaling 383 accesses), and Mac OS systems showed sparse ECH support limited to Firefox on older macOS and Chrome on macOS 10.15.7. A single GREASEd access from iPadOS/18.0 (Mobile Safari) was the only signal of any Apple ECH awareness.

§6.3, Table 5; §6.5 evaluation

In a 41-day real-world ECH trial (2025-05-01 to 2025-06-11) across 14 server instances in 7 global data centers, 64% of accesses came from ECH-aware clients (success or GREASE) while 36% did not attempt ECH at all. Of 4,074 total log events, 1,660 were ECH successes, 825 were GREASE, and 1,589 were not-tried, indicating that today roughly 41% of traffic benefits from full ECH privacy protection. The trial found no measurable service disruption from enabling ECH.

§6.1, Table 3 evaluation

Wikimedia's preferred deployment mode — ECH split-mode, which would use a third-party front-end's IP addresses to bypass IP-level blocking of Wikimedia's own address space — could not be trialed because no suitable front-end partner was found. Potential operators declined due to concerns about traffic volume, risk of inheriting Wikimedia's blocked reputation, or lack of a compatible business model.

§2 deployment

The DEfO project backported ECH support to nginx 1.22.1 (Debian bookworm's shipped version) and deployed it at 14 instances across 7 Wikimedia data centers with no service disruption over 41 days. The primary operational barrier was institutional review process for custom-built binaries and the novel HTTPS RR DNS record type, adding only a few days to the deployment timeline.

§3, §4, §7 deployment

Across all 7 global data centers (EU, USA, Singapore, Brazil), every data center recorded ECH successes with no observed evidence of regional ECH blocking or interference. ECH-aware client percentages varied by region — EU 75%, North America 63%, Asia 49%, South America 46% — but this was attributed to browser version distribution rather than censorship. The trial spanned 14 geographically distributed PoPs.

§6.2, §6.5, Table 4 evaluation

A Russian user ran a self-built snowflake-proxy from inside the censored country using the 'random-and-mimic' fingerprint option, successfully serving Iranian, Turkmen, Russian, and German Tor users, demonstrating that the blocking is unidirectional (targeting client DTLS hellos) and that snowflake-broker and rendezvous domains (snowflake-broker.torproject.net, snowflake-01/02.torproject.net) remained accessible behind the .net SNI — only the DTLS data channel was filtered.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 original report, Issue #422 comment tls-fingerprintsni-blocking

In AS197207 (Iran, MCI), approximately 50% of DoT endpoints failed consistently — the only case across all tested ASN/protocol combinations where failure exceeded 20%. In Kazakhstan (AS48716) and China (AS45090), more than 80% of DoT and DoH endpoints were always reachable.

2021-basso-measuring §V-F, Table VII ip-blockingsni-blockingtls-fingerprint

As of July 2019, approximately 10.93% of the Alexa top 1 million websites support ESNI (all via Cloudflare CDN, which enabled ESNI across all its platforms in September 2018), with 92.56% of Cloudflare-hosted sites using encrypted SNI over TLS 1.3. However, fewer than 0.01% of observed TLS ClientHello messages in the wild contained an ESNI extension, revealing a severe gap between server-side readiness and client-side adoption.

2019-chai-importance §4.2, §5.1 sni-blockingtls-fingerprint

Real-world CDN HTTPS deployments leak the identity of visited websites through three distinct channels — TLS certificate contents (A2, B1, B2 deployments), the plaintext SNI field (B1), and dedicated IP address mappings (B2) — enabling censors to block CDNBrowsing connections via standard DPI or IP filtering without collateral damage to non-forbidden CDN content. Each leakage channel requires inspecting only a single packet from an HTTPS connection, making the attack low-cost and deployable on off-the-shelf censorship boxes.

2016-zolfaghari-practical §3.1 dpisni-blockingtls-fingerprintip-blocking

As of 2015, TLS tampering detection was implemented by only a small minority of surveyed censorship measurement tools: explicitly by Holz et al.'s Crossbear (2012) and OONI (2012), and partially by Soghoian and Stamm (2011) and UBICA (2013). The majority of the 13+ surveyed platforms detected DNS tampering and HTTP manipulation but lacked TLS coverage, creating a systematic blind spot in published censorship measurement.

2015-aceto-internet Table 2 tls-fingerprintsni-blocking

Tor's TLS handshake exhibited multiple distinguishing fingerprints — including the client cipher list, server certificates, and randomly generated SNIs — that were used for TLS-based filtering in Ethiopia, China, and Iran. Inferring the exact byte-level pattern matched by DPI boxes required manual analysis and remains a difficult open problem as of 2013.

2013-winter-towards §3.1.5, §5 tls-fingerprintdpisni-blocking