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

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
-----------------------------------------+--------------------------
 Reporter:  dcf                          |          Owner:
     Type:  project                      |         Status:  reopened
 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):

 Yawning contributes some observations:

 > Replying to [comment:32 dcf]:
 > > The delay can be up to 10 ms. Why this may be a problem is the sleep
 happens during thr round trip between client and server. If the round-trip
 time is greater than the delay, then it is as if there was no delay.
 Delays happen only once per write (i.e. obfs4 doesn't split up writes to
 insert delays). So the timing obfuscation may be less effective during the
 handshake phase than during the steady state, which can have consecutive
 writes not bound by latency.
 >
 > It *can* split writes to insert delays.  See `iat-mode=2`.
 >
 > > Another potential problem is that the obfs4 code dies on short writes.
 This is actually documented:
 > > https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/tree/transports/obfs4/obfs4.go?id=df6aeeca8cc8e953284ce1cb8a0910500579dfaf#n512
 > > {{{
 > > // Write the pending data onto the network.  Partial writes are fatal,
 > > // because the frame encoder state is advanced, and the code doesn't
 keep
 > > // frameBuf around.  In theory, write timeouts and whatnot could be
 > > // supported if this wasn't the case, but that complicates the code.
 > > }}}
 > > It sounds like kzblocked has actually gotten it to happen, maybe on a
 slow link. They were going to find out what `err` is when a short write
 happens.
 >
 > Unless they're messing with the send socket buffer size and setting it
 to something pathologically low, this should basically never happen (to my
 knowledge, no one has complained about it).  I think this is a red
 herring.
 >
 > (And if they are, why.  There's better ways to regulate write size.)
 >
 > The correct way to fix this sort of attack is to switch to a model where
 the transport schedules writes on it's own regardless of if it has data
 queued or not.  I was going to do something like that for my obfs4
 successor, but development on that is on hold for now, and I don't know
 when I'll get back to it.  There's easier distinguishers for obfs4 traffic
 than this sort of analysis anyway....

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