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

[Tor Bug Tracker & Wiki]

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

Comment(by phw):

 Replying to [comment:10 isis]:

 > Replying to [comment:7 phw]:
 > > * 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?
 > UAE and Ethiopia block all SSL, correct?
 >
 > If so, there seems to be not much that Tor or any bridge tests can do
 about that, at least not until more pluggable transports are deployed.

 It does not look like UAE is blocking Tor at the moment but Ethiopia is
 dropping the Tor TLS client hello and server hello. All the details are in
 the one and only
 [https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki
 censorship wiki]! SSL in general is not blocked, though.

 > > 2. I haven't seen any evidence for service enumeration. Is this still
 supposed to happen?
 >
 > This is what I read, and if it is the case, i.e., that China blocks by
 IP:port if there are other services, and elif by IP blackholing, then it
 would make testing easier because, as I mentioned earlier, it would be
 pretty trivial to fake services on a bridge that we set up (that way we
 could just change the port to continue bridge reachability testing). If
 you're not seeing it though, I suppose you've probably got more info on
 this than anyone else, so it might not be happening anymore. Does this
 mean they always dumb block on IP:port? Or are they always blackholing?

 Yes, it looks like bridges (and even relays) are blocked by IP:Port. I
 only saw IP blackholing for the directory authorities. I think that from
 the GFC's point of view that's quite good: It has no collateral damage and
 is still highly effective.

 > > 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.
 >
 > I'd take a look at it. Do you think the "twelve hours without a
 successful connection from the probe" still applies to unblocking?

 I reproduced this a couple of weeks ago and was able to unblock bridges
 after just 2-3 hours. The time seems to vary but it should still work,
 yes.

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