#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs