Analyzing China's Blocking of Unpublished Tor Bridges

By 2018 the GFW shifted from blocking Tor bridges by (IP, port) tuples to blocking the entire IP address. A blocked bridge remains inaccessible for exactly 12 hours; the block renews to 12 hours if any additional Tor connection attempt is made during that window, after which the GFW re-scans and removes the IP from the blacklist if Tor is no longer running.

§4.2 detection dpiactive-probingip-blockingrst-injection cn

The authors attracted 934 unique scanner IPs over 44 hours, all geolocated to China, with TTL values clustered at 48–50 and MSS of 1400 (with a secondary cluster at 1368 from IP 111.202.242.93). 908 IPs conducted exactly one scan and 26 conducted two; no IP scanned more than twice, indicating deliberate distribution to resist IP-based blacklisting of scanners.

§4.3 detection active-probing cn

Meek over Azure CDN successfully established Tor circuits from China in all tests; meek over Amazon was inconsistent and often failed mid-circuit. Meek requires TLS on the bridge — without it the GFW blocks the bridge within minutes and purges it from the blacklist, suggesting a separate meek-specific detection and blocklist is maintained.

§5.1 evaluation dpiactive-probing cn

obfs4 successfully established Tor circuits on the authors' own unpublished bridge relays but failed to connect to any public obfs4 bridge, consistent with the GFW having scraped and blacklisted public bridge addresses. This demonstrates that address confidentiality is a prerequisite for obfs4's effectiveness, independent of its obfuscation properties.

§5.1 evaluation dpiactive-probingip-blocking cn

Configuring iptables to drop incoming Tor packets whose TCP MSS equals 1400 (the value observed on GFW scanners) prevented bridge IPs from being added to the blocklist across the entire 44-hour experiment. This technique requires changes only on the relay, unlike pluggable transports that require both client and server upgrades.

§5.2 defense active-probing cn