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

[Tor Bug Tracker & Wiki]

#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 phw):

 I am probably just stating the obvious here but perhaps I have some useful
 remarks:

  * UAE and Ethiopia do not actually block bridges but rather network
 packets. We need to distinguish between blocking Tor by protocol and by
 end points (bridges/relays). Also, Lebanon and Qatar are new to me. It
 would be helpful to add them to the
 [https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki
 censorship wiki] in case anybody knows more about that. Apart from China,
 is there any country actually blocking bridges by IP and port at the
 moment?

  * I have a pcap file containing the connections of several hundred
 Chinese probes over a period of several weeks. It could be used for TTL
 analysis etc. Drop me an e-mail if you are interested in the data set.

  * A censor could also silently block bridges while at the same time
 initiating dummy Tor connections to them so we wouldn't see the block in
 the usage statistics. However, we will probably still be able to detect
 this by users complaining over e-mail.

  * The following is probably non-trivial but aside from the country-level
 usage statistics, the feedback loop to scan bridges could also consider
 passive individual bridge usage statistics. E.g., if a bridge recently saw
 a connection from a censoring country, it might be reachable. On the other
 hand, if a bridge has not seen connections in ''n'' days, it might be
 worth scanning.

  * As mentioned above, I think that packet fragmentation could be a good
 way to scan bridges in China without triggering follow-up scanning. On a
 more general note, we might have to come up with country-specific plans to
 scan bridges without leaving dozens of blocked bridges behind us.

 Regarding the open questions:

  2. [http://www.cs.kau.se/philwint/censorbib/#Xu2011 This paper] contains
 some additional information about the Chinese filtering infrastructure;
 especially with respect to the filtering ASes.
  2. That's hard to answer, given that I could not initiate any
 communication with the probes other than the bridge scan. Figure 2a) in my
 paper shows when we were able to communicate with what we believed was the
 host "behind" the probe. Also, keep in mind that the IP hijacking is just
 a hypothesis at this point and the evidence is not strong enough to
 consider it as fact.
  2. I haven't seen any evidence for service enumeration. Is this still
 supposed to happen?
  2. It looks like the old concept of "scanning queues" in 15 minute
 intervals changed a couple of weeks ago. What I am seeing now is real-time
 scans which happen immediately after the GFC detected a potential Tor
 connection. Then, you won't see any scanners for ~20 minutes even though
 you continue initiating Tor connections. After ~20 minutes, there are
 real-time scans again. I have yet to take a closer look at the data. If
 anybody wants to help, drop me an e-mail.

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