Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-08

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#20348: Kazakhstan blocking of vanilla Tor, 2016-08
-----------------------------------------+---------------------
 Reporter:  dcf                          |          Owner:
     Type:  project                      |         Status:  new
 Priority:  Medium                       |      Milestone:
Component:  Metrics/Censorship analysis  |        Version:
 Severity:  Normal                       |     Resolution:
 Keywords:  censorship block kz          |  Actual Points:
Parent ID:                               |         Points:
 Reviewer:                               |        Sponsor:
-----------------------------------------+---------------------

Comment (by dcf):

 I was talking to someone on IRC today (I'll call them kzblocked) who
 provided some information. As I understand them:
  * Vanilla Tor, obfs3, obfs4, and meek are blocked.
  * The blocking is unreliable and seems to depend on load. Sometimes
 traffic gets through that you would think would get blocked. This makes it
 harder to test. The firewall is also blocking tumblr.com (by SNI) but
 sometimes it loads.
  * Secret obfs4 bridges from bridges.torproject.org are also blocked. It
 seems to be dynamic detection, not a static blacklist. Setting `iat-
 mode=1` on the client doesn't help.
  * meek is blocked by SNI. [[doc/meek#Howtochangethefrontdomain|Changing
 the front domain]] circumvents the block. kzblocked didn't try a different
 TLS fingerprint.
  * obfs2 isn't blocked; kzblocked speculates it's because the initial
 packet is too short to get a good entropy estimate.
  * The blocking of vanilla started on June 2. Bridges were somehow lagged
 or degraded so people gradually stopped using them.
  * Behavior differs across ISPs. Someone said that in one case it's a
 Fortinet FortiGuard firewall.

 kzblocked wrote a Windows program that allows obfs4 connections to
 succeed, by shrinking the server's TCP window so the client's first packet
 is smaller. Like [https://github.com/NullHypothesis/brdgrd brdgrd] but on
 the client side. They seem to think that only the first segment is being
 looked at.
  * A first segment of 1 byte doesn't work.
  * A first segment of 16 bytes works.
  * A first segment of 16 bytes works also for unobfuscated Tor TLS.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20348#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs