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

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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:          
--------------------------------------------------------------------------------+
Changes (by isis):

  * status:  new => accepted


Comment:

 Replying to [comment:7 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?
 >

 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.

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

 Awesome!

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

 That would be horrible. Though, we could still do frequency analysis on
 the traffic going through a bridge we suspect that of happening to,
 because I doubt that a dummy connection would be capable of generating
 realistic looking traffic (it's possible, it would just be more work on
 the censor's part). However, monitoring traffic frequency would require
 extra code added to little-t tor, it's obviously not something we could do
 from a scanner.

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

 That seems do-able...and useful too.

 If that were to be implemented, I think it would make sense for metrics-db
 to have an extra folder or field, some way of keeping state and storing
 the number of connections from a given country over time, and then the
 scanner could both update that data and parse it every so often, then feed
 it into whatever algorithm decides if changes look too drastic or sketch.

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

 Yes, either the scanner will have to be very "intelligent", or there will
 have to be per-country rules. I'd opt for the former, because it's less
 work later if the thing adapts by itself.

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

 Neat, reading material for the next flight! :)

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

 Right. I looked a bit more into how this could be done, and I found a tool
 called [https://code.google.com/p/exabgp/ exabgp] which enables the
 injection of ASes (actually most state-level actors probably don't need
 that, because they control the ASes anyway), and then applying packet-
 labels with LSRs and using MPLS to direct the appropriate flow to/from the
 probe and the rest to the actual host. This IP-hijacking, if it is indeed
 happening is something which I do not yet fully comprehend, but it is very
 interesting.

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

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

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