[tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications hardware, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4 by Allot Communications
hardware, 2016-06
-----------------------------------------+-------------------------
 Reporter:  dcf                          |          Owner:
     Type:  project                      |         Status:  closed
 Priority:  Medium                       |      Milestone:
Component:  Metrics/Censorship analysis  |        Version:
 Severity:  Normal                       |     Resolution:  invalid
 Keywords:  censorship block kz          |  Actual Points:
Parent ID:                               |         Points:
 Reviewer:                               |        Sponsor:
-----------------------------------------+-------------------------

Comment (by dcf):

 I am more and more convinced that what we are dealing with, with respect
 to obfs4 blocking, is mainly a blacklist. It is not just a simple firewall
 rule, because connection are allowed initially but not allowed to persist.
 Perhaps it also takes into account some timing-based features, but
 primarily it seems to be a blacklist.

 See, for example, the graphs for Lisbeth and NX01:443 in comment:193.
 There is a visible change around 2017-01-26 (actually it must have
 occurred during an outage of the VPN, between 2017-01-25 16:33:55 and
 2017-01-27 00:29:43). Before this date the bridges virtually always
 bootstrap 100%; after that they usually reach 25% and occasionally 100%.
 If 2017-01-26 is the date when the bridges were blacklisted, it means that
 Kazakhstan's reaction time is much slower than China's. China blocked
 Lisbeth on 2016-10-19 (22 days after #19838 merged) and NX01:443 on
 2016-12-04 (68 days after #19838 merged, 2 days after #20838 merged).
 Kazakhstan was 100 days slower to block Lisbeth, and 54 days slower to
 block NX01:443.

 Part of the confusion we've had in detecting whether blocking was
 occurring might have been caused by failures on the bridge side. As you
 can see from the graph in comment:193, some of the default bridges were
 down (even from the U.S.) at various times. ndnop3 and ndnop5 (from
 comment:47) are interesting cases, because they have been failing
 connections even from the U.S. about 40% of the time. In communication
 with the bridges' operator, we tracked the problem down to a file
 descriptor limit. This may explain some of the irregular results we were
 seeing early on.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20348#comment:195>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online