[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:      
--------------------------------------------------------------------------------+

Comment(by 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.))?

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

 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?

 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..

 f) What about reachability testing on bridges that support pluggable
 transports?

 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"?

 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:2>
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