[tor-bugs] #5028 [Ooni]: Tor bridge scanning

[Tor Bug Tracker & Wiki]

#5028: Tor bridge scanning
---------------------+------------------------------------------------------
 Reporter:  hellais  |          Owner:  runa                     
     Type:  project  |         Status:  assigned                 
 Priority:  normal   |      Milestone:  Sponsor F: March 15, 2012
Component:  Ooni     |        Version:                           
 Keywords:           |         Parent:                           
   Points:           |   Actualpoints:                           
---------------------+------------------------------------------------------

Comment(by karsten):

 Replying to [comment:36 ioerror]:
 > Replying to [comment:33 karsten]:
 > > I think I understand your concerns.  But that doesn't mean it's
 impossible to obtain "some sort of automated ground truth of bridge
 reachability from some countries" which is what we promised in the
 deliverable.
 >
 > We already have that ground truth, don't we?

 We seem to have some knowledge about how .cn blocks Tor.  But we're
 looking for an automated way to detect whether bridges are reachable from
 any given country.  If some other country starts blocking bridges tomorrow
 we'll want to have an automated way to detect that.

 I ran a scan from .de yesterday and can say that we have very few false
 positives and false negatives in finding which bridges are reachable.  No
 big surprise, but useful to confirm that the scanner is working correctly.

 Runa is going to run the same scan from .cn today, twice with a delay of
 one hour.  Will all bridges be unreachable?  Just the ones that are new
 and were not used from .cn yet?  Will the ones which were working in the
 first scan be blocked in the second scan?  How will the reported bridge
 statistics tomorrow differ from the statistics today?  That's stuff we
 hope to learn, and we can't just guess what will happen.

 Maybe we should run a third scan from another country.  How about .ru?  Do
 we know if bridges are blocked from .ru?  And do we know whether a simple
 TCP scan with a timeout of 20 seconds will give us reliable information
 which bridges are reachable?

 > Obfu bridges are generally reachable, tls bridges are generally blocked
 either before we test or by confirmation with a follow up probe. Has that
 changed?

 I wouldn't know.

 > Are we doing a scan of the obfu bridges? Or just the normal HTTPS/TLS
 bridges?

 We're scanning normal HTTPS/TLS bridges, no obfsproxy bridges.

 > > The TCP scan of HTTPS bridges may not be the best approach, but it's
 the best we have right now.  At least so far I only heard "oh noes, don't
 do it," not "here's a better way to deliver what we promised, and we can
 do it within 3 days."  Until I hear the latter I'll stick with the
 approach we have.  I don't know if the results will be conclusive, but I
 sure want to find out.
 >
 > My suggestion is to deliver the news that we know without impacting the
 resources which are scarce. The fact that the ground truth is now "active
 probing" is really quite a thing! If that is indeed still happening, of
 course.

 I think that's great to know, but it's not what we hope to learn in this
 deliverable.

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