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

Re: [tor-bugs] #6414 [Ooni]: Automating Bridge Reachability Testing

#6414: Automating Bridge Reachability Testing
--------------------------------------------------------------------------------+
 Reporter:  isis                                                                |          Owner:  isis
     Type:  project                                                             |         Status:  new 
 Priority:  normal                                                              |      Milestone:      
Component:  Ooni                                                                |        Version:      
 Keywords:  bridge-reachability metrics-db automation testing SponsorF20121101  |         Parent:      
   Points:                                                                      |   Actualpoints:      
--------------------------------------------------------------------------------+
Changes (by aagbsn):

 * cc: aagbsn (added)


Comment:

 Replying to [comment:2 asn]:
 > Some comments:
 >
 > a) The GFC DPI/probing description is not entirely correct, but it
 shouldn't matter too much for reachability testing. Read Philipp's paper
 for more information (for example, the fpr is in the ClientHello, the
 probers do full SSL and send a CREATE Tor cell, etc.).
 >
 > b) How many bridges should you test each time? Should we test _all_
 bridges, or just a small sample of bridges (with diverse characteristics
 (like country, tor version, etc.))?

 No single measurement point should have a complete view of all the
 bridges.

 How often are bridges being scanned? Hourly? Daily? Weekly? Longer?

 Keep in mind that if BridgeDB stop handing out bridges that are known to
 be blocked, and replaces them with new bridges, those bridges may get
 blocked too (example, a client that is mining bridges receives new bridges
 and blocks those too). We can control the rate that BridgeDB consumes
 reachability data -- that gives us a knob to play around with the rate
 that bridges get burned (though this rate can be different than the scan
 rate)

 >
 > c) How much do we care about burning a bridge during reachability
 testing?

 What scenarios do you think could cause a bridge to get burned in a way
 that would not also apply to every other bridge being scanned as well?

 >
 > d) In which cases can we detect blocking during reachability testing in
 real-time, so that we don't burn our whole list of bridges in a single
 testing session? Is the price of bridges higher than the implementation
 pain of detecting real-time blocking?

 Perhaps double-checking bridges from another host and aborting the scan if
 the results differ by some configurable threshold would work for the
 active-direct methods.

 >
 > e) Should we set our own bridges for reachability testing? This way, we
 have control over the bridges and we can pivot their TCP port if the
 blocking is IP:PORT-specific etc..

 This sounds like a good use of contact information in the bridge-
 descriptor.
 >
 > f) What about reachability testing on bridges that support pluggable
 transports?

 This is also a necessary component for the Bridge Authority -- bridges
 (0.2.4) can spam whatever transport lines they please, and BridgeDB eats
 it up and advertises it. For every pluggable transport type, there ought
 to be a corresponding reachability test.
 >
 > g) Is there a point in performing less-useful tests than '''Tor
 TLS/SSLv3 Handshake'''? Since we will always be interested in performing
 the "dangerous" '''Tor TLS/SSLv3 Handshake''' test we might as well start
 with it, instead of incrementally performing less-dangerous tests. This
 comes down to "how much do we care if we burn a single bridge"?

 Yes, if it means that the *scanner* is harder to detect. We do not want
 the measurement points to be targetted.

 >
 > Or are you interested in finding if they will block you in real-time,
 and the point of all the incremental testing is to bisect in which layer
 it happens? This sounds like a fun idea, but maybe we should separate
 'reachability testing' and 'real-time DPI censorship detection' '''for
 now''' so that the implementation plan does not get too bloated.

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