FOCI 2018: Analyzing China's Blocking of Unpublished Tor Bridges

[David Fifield]

Arun Dunna, Ciarán O'Brien, and Phillipa Gill
https://www.usenix.org/conference/foci18/presentation/dunna

An updated study on the blocking of relays and bridges by the GFW, in
the tradition of https://censorbib.nymity.ch/#Winter2012a and
https://censorbib.nymity.ch/#Ensafi2015b. They have three bridges, two
relays, and a scanning machine in Shanghai. They also look at some
relays that appear publicly in the Tor consensus. As in the earlier
studies, they find a wide diversity of scanner IP addresses (all located
in China), almost all of which appear only once. The previously
documented outlier scanner at 202.108.181.70 is now absent from their
set of 934 scanner addresses captured over 44 hours; it has seemingly
been replaced by 111.202.242.93 which accounts for 5% of all probes.
111.202.242.93 differs from the other scanners in other ways: in TCP
fingerprint, and in that probes from it alone are not enough to cause a
bridge to get blocked.

Directory authorities and public relays are blocked by TCP RST. Newly
introduced relays are blocked within 10 minutes of being published. The
IP address remains blocked for 12 hours, after which it is scanned
again, and removed from the blocklist if no longer a relay. Bridges are
also blocked by TCP RST and connection attempts provoke active probing,
not only to the destination port, but also to common ports like 80 and
443, and to numerically close ports. Active probing lasts for about one
minute, then stops. As with relays, blocked bridges are re-scanned every
12 hours, and removed from the blocklist when they are no longer
bridges. The common delay of 12 hours suggests that active-probed
bridges and relays scraped from the consensus wind up in the same
bucket. Notably, no other scans occur during the 12-hour intervals, even
if additional connection attempts are made.

Unlike in https://censorbib.nymity.ch/#Ensafi2015b, blocks were not of
individual ports, but of all ports on an IP address, which makes it
harder to collect samples of scanner traffic, because scans only happen
once every 12 hours per IP address. To work around this, they develop an
approximate TCP fingerprint for the scanners and block connection
attempts from them, allowing them to rapidly trigger new scans. They
suggest that the same technique—dropping incoming TCP packets with an
MSS option of 1400—could be used to protect operational bridges.

Unpublished meek and obfs4 bridges remained unblocked. An interesting
tidbit: they tried setting up a meek server without TLS (which is in
principle easily detectable) and found that the server got blocked.