2020-gfw-esni-blocking

Exposing and Circumventing China's Censorship of ESNI

GFW Report team · gfw.report · 2020

Abstract

August 2020 documentation of the GFW's blocking of TLS Encrypted SNI (ESNI) traffic, with details on how the blocking is implemented and proposed circumvention approaches.

Team notes

Historical: the GFW began blocking ESNI in 2020, well before ECH rollout in browsers. Lantern protocol designs that assume ECH gives hostname privacy in CN need to start from this paper. ECH-based defenses haven't been a major Lantern bet yet but anyone considering it should know this is the prior art and the GFW already has detector code.

Tags

censors: cn
techniques: esni-eh-blocking sni-blocking dpi
defenses: ech-esni mimicry
method: measurement-study

findings extracted from this paper

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.

Strategy 2: Four Byte Segmentation defense esni-eh-blockingdpi cn
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.

Evasion strategies / Summary on Circumvention Strategies defense esni-eh-blocking cn
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 censors ESNI, but not omit-SNI / New extension values are not blocked detection esni-eh-blockingdpi cn
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.

Details About the Blocking detection esni-eh-blockingdpitls-fingerprint cn
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.

Residual Censorship detection esni-eh-blocking cn