[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

#20348: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf.
cyberoam assists bloody dictatorships.
-----------------------------------------+-------------------------
 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 made some visualizations of packet timing. The source code for these is
 in !https://www.bamsoftware.com/git/garden.git.

 The orange lines above the axis are sent packets and the blue lines below
 the axis are received packets. I let the tor client bootstrap to 100% and
 then cut off the graphs at 6 seconds. I repeated each bootstrap 3 times.

 The main observation is that the initial obfs4 handshake and TLS handshake
 are not really affected by the `iat-mode`, because the round-trip time
 swallows all the added delays.

 == non-obfuscated ==

 For comparison, this is a non-obfuscated, non-default bridge. The first
 little blip at 0 seconds is the client SYN. The three lines after that are
 the TLS handshake. What follows after that is TLS application data, the
 Tor protocol.

 [[Image(timing-eRYaZuvY02FpExln-or.png)]]

 == obfs4 iat-mode=0 ==

 This is the default bridge riemann with `iat-mode=1`. The first blip at 0
 seconds it the client SYN. The one after that is the client obfs4
 handshake including padding. The one after that is the server obfs4
 handshake plus padding, and the Client Hello.

 You can see that even though the obfs4 padding is a lot of bytes, it
 doesn't affect the timing signature much, which is dominated by latency.
 The same pattern from the vanilla graph is visible, just offset a bit.

 [[Image(timing-riemann-obfs4iat0.png)]]

 This is the non-default `iat-mode=0` bridge from comment:10. It looks
 about the same as riemann. In try !#1 there was a little delay (a similar
 thing appears in some other graphs below), maybe caused by a dropped
 packet or something.

 [[Image(timing-unused-obfs4iat0.png)]]

 == obfs4 iat-mode=1 ==

 This is the default bridge ndnop3 from comment:47 with `iat-mode=1`. What
 we see here is that the first part—the obfs4 handshake and the TLS
 handshake—isn't changed much, as suspected in comment:32. It's a bit more
 spaced out because of a higher latency to this particular bridge. Only
 when the client starts downloading a big chunk of data does the extra
 padding and timing obfuscation start to have an effect.

 [[Image(timing-ndnop3-obfs4iat1.png)]]

 This is the non-default `iat-mode=1` bridge from comment:10. The first
 part of the diagram is again not much changed. Once the real data transfer
 starts, the extra padding and timing obfuscation starts to have an effect
 and increases bootstrap time from 2 seconds to 3 seconds.

 [[Image(timing-unused-obfs4iat1.png)]]

 == obfs4 iat-mode=2 ==

 This is the default bridge ndnop5 from comment:47 with `iat-mode=2`. The
 signature of the first few packets is again not much changed. Once the
 download begins, you can see that `iat-mode=2` is a lot more expensive
 than `iat-mode=1` (the edge of the blue lines is ragged because it doesn't
 try to fill the MTU).

 [[Image(timing-ndnop5-obfs4iat2.png)]]

 This non-default bridge from comment:10 looks about the same.

 [[Image(timing-unused-obfs4iat2.png)]]

 == overloaded obfs4 iat-mode=0 ==

 Finally, here is the default bridge Lisbeth from comment:51. It has `iat-
 mode=0`, but it doesn't seem blocked yet. kzblocked guessed in comment:64
 that it might be due to load on the bridge. Indeed, its timing signature
 looks a lot different from the other `iat-mode=1` bridges—it's slower and
 more irregular.

 [[Image(timing-Lisbeth-obfs4iat0.png)]]

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20348#comment:68>
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