TECHNIQUES
esni-eh-blocking Encrypted ClientHello / ESNI blocking
Synonyms: ECH blocking, ESNI blocking
10 papers on file
- 2025-niere-encrypted Encrypted Client Hello (ECH) in Censorship Circumvention
- 2025-vafa-learning Learning from Censored Experiences: Social Media Discussions around Censorship Circumvention Technologies
- 2021-kwan-exploring Exploring Simple Detection Techniques for DNS-over-HTTPS Tunnels
- 2021-xue-throttling Throttling Twitter: an emerging censorship technique in Russia
- 2020-gfw-esni-blocking Exposing and Circumventing China's Censorship of ESNI
- 2019-chai-importance On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention
- 2019-sheffey-improving Improving Meek With Adversarial Techniques
- 2015-crandall-forgive Forgive Us our SYNs: Technical and Ethical Considerations for Measuring Internet Filtering
- 2013-anderson-dimming Dimming the Internet: Detecting Throttling as a Mechanism of Censorship in Iran
- 2012-verkamp-inferring Inferring Mechanics of Web Censorship Around the World
11 findings tagged here
-
Encrypted DNS (DoH, DoT) and Encrypted ClientHello (ECH) fully hide plaintext domain names from on-path observers but leave destination IP addresses visible, enabling IP-based fingerprinting with no protocol-level metadata required. An adversary collecting only NetFlow/IPFIX destination-IP records—without TLS fingerprints, packet timing, or port metadata—correctly identifies 72% of all 520K dual-stack websites over IPv4 and 68% over IPv6.
-
Firefox adopted DTLS 1.3 by default for WebRTC in May 2024 (version 127); Chrome has implemented DTLS 1.3 in BoringSSL but not yet enabled it by default. DTLS 1.3's Encrypted Client Hello (ECH) extension would encrypt extension lists and make passive field-based fingerprinting of those extensions obsolete — but censors may choose to block DTLS 1.3 ECH unless browsers adopt it widely enough that blocking causes unacceptable collateral damage. The Pion library (used by Snowflake standalone proxies) has no concrete roadmap for DTLS 1.3 support, creating a growing gap.
-
Of 640,694 TLS 1.3 servers in the Tranco Top 1M (Feb 2025), 51.28% parse ECH extensions but only 43% actually handshake ECH — and virtually all of those are Cloudflare servers (278,040). Only 6 non-Cloudflare servers successfully handshaked ECH. Cloudflare's own servers have a 44% non-advertisement rate: servers that can handshake ECH but do not publish their ECH configuration in DNS, typically because the operator manages their own DNS outside Cloudflare. The total number of advertised ECH configurations dropped from ~180,000 in November 2024 to ~150,000 by April 2025.
-
Chrome and Firefox send GREASE ECH extensions in every ClientHello message, meaning a censor that blocks all ECH-containing ClientHellos would block all Chrome and Firefox TLS traffic. Cloudflare's static outer SNI "cloudflare-ech.com" in all its ECH configurations makes real ECH connections trivially distinguishable from GREASE ECH — censors can block real ECH connections to Cloudflare without triggering GREASE collateral damage. Cloudflare rejects ECH handshakes with omitted or invalidated outer SNI values; non-Cloudflare ECH deployments accept missing and invalid outer SNIs.
-
Only 1.5–2.25% of domains from TLD zone files have a valid ESNI key, with 15.4K of the top 100K and 143.3K of the top 1M popular domains supporting ESNI. All ESNI-supported domains are hosted by Cloudflare, making ESNI-enabled connections trivially distinguishable from the vast majority of TLS traffic and a low-collateral-damage blocking target for censors.
-
China's GFW blocks all ESNI traffic via RST packet injection following a TLS ClientHello with an encrypted SNI field, confirmed since July 2020. Russia blocks ESNI in a decentralized, ISP-level fashion across at least three identified ASes (AS28890, AS52207, AS41754), each injecting RST packets independently.
-
Splitting the TLS ClientHello so that the first TCP segment is ≤4 bytes (less than the 5-byte TLS record header) defeats the GFW's ESNI detection with near 100% reliability. Geneva expressed this as `[TCP:flags:PA]-fragment{tcp:4:True}-|` (client-side) or a server-side window-size reduction to 4 bytes that forces the client to segment. This suggests the GFW's ESNI classifier cannot reassemble TCP segments across all protocol contexts.
-
Geneva discovered 6 client-side and 4 server-side TCP-layer evasion strategies against GFW ESNI blocking within 48 hours of training, all achieving near 100% reliability. Effective strategies include desynchronization attacks (triple SYN with corrupt sequence number, FIN+SYN flag confusion, TCB turnaround via pre-handshake SYN+ACK) and TCB teardown via corrupted-checksum RST injection. All strategies operate at the TCP layer and require no changes to the application sending ESNI.
-
The GFW's ESNI detector is keyed specifically to extension value `0xffce` (ESNI draft-01). Replacing `0xffce` with ECH draft values `0xff02`, `0xff03`, or `0xff04` produced no blocking as of August 2020. This indicates the GFW deployed a detector matching on a specific extension ID rather than detecting encrypted SNI generically.
-
The GFW blocks ESNI by dropping client-to-server packets whenever a TLS ClientHello containing the `0xffce` encrypted_server_name extension is sent over a completed TCP handshake. Unlike GFW censorship of SNI and HTTP (which uses RST injection to both endpoints), ESNI censorship uses unidirectional packet dropping with no injected packets. The blocking applies on all ports from 1 to 65535.
-
After a GFW ESNI block is triggered, residual censorship persists for 120–180 seconds (varying by vantage point), blocking all traffic on the same (srcIP, dstIP, dstPort) 3-tuple. Additional ESNI handshakes sent during the residual window do not reset the timer, and it takes at least 1 second for the GFW to enable blocking rules after the triggering packet.