[tor-bugs] #20348 [Metrics/Censorship analysis]: Cyberoam assists dictatorship regimes with murders

[Tor Bug Tracker & Wiki]

#20348: Cyberoam assists dictatorship regimes with murders
-----------------------------------------+---------------------------------
 Reporter:  dcf                          |          Owner:
     Type:  project                      |         Status:  closed
 Priority:  Medium                       |      Milestone:
Component:  Metrics/Censorship analysis  |        Version:
 Severity:  Normal                       |     Resolution:  user
                                         |  disappeared
 Keywords:  censorship block kz          |  Actual Points:
Parent ID:                               |         Points:
 Reviewer:                               |        Sponsor:
-----------------------------------------+---------------------------------

Comment (by dcf):

 kzblocked investigated obfs4proxy and found some potential explanations
 for how obfs4 is being blocked. I'll try to summarize what I read on IRC.

 As we've seen above, some kind of DPI is blocking obfs4. The blocking
 seems probabilistic, not total, and default bridges are more likely to be
 blocked than custom bridges. kzblocked suspects that the DPI is reading
 about 50 KB of data and then building a timing signature of about 6 data
 points: 2 from the obfs4 handshake and 4 from the TLS handshake. Each data
 point is a sequence of segments terminated by one with the PSH flag set.

 A potential problem is that obfs4proxy implements timing obfuscation by
 doing a sleep ''after'' each write:
 https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/tree/transports/obfs4/obfs4.go?id=df6aeeca8cc8e953284ce1cb8a0910500579dfaf#n559
 {{{
 // Write then sleep.
 _, err = conn.Conn.Write(iatFrame[:iatWrLen])
 if err != nil {
         return 0, err
 }
 time.Sleep(iatDelta * time.Microsecond)
 }}}
 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.

 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.

 kzblocked believes that the firewall hardware is Sophos Cyberoam devices.
 I don't know of any evidence for that fact, except that the blocking of
 obfs4 is consistent with a past report (May 2016) about Cyberoam devices:
 https://lists.torproject.org/pipermail/tor-talk/2016-May/040898.html

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