[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:40 ioerror]:
 > It seems like such an automated scan should contain special cases for
 countries with network censorship systems that are as advanced as China.

 Sure.  In the long run we could do full Tor handshakes for most countries
 and just the TCP scan for China.  But we'll have to start somewhere, and
 the TCP scan seems to be the safest approach.

 > > > 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.
 >
 > This is a test that seems extremely relevant and if we're going to do
 scans from China, I bet it's one of the safest and most useful.

 If we only scan obfsproxy bridges, we'll only learn if those are
 reachable.  But we want to have a mechanism for telling if normal bridges
 are reachable as well.  Excluding obfsproxy bridges for the moment.

 > > > 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.
 >
 > Ok. Are we scanning from all buckets or just a single bucket?

 The plan was to scan all HTTPS bridges, but I guess we can reduce that to
 2 out of 5 rings.  125 bridges in total.

 > The ground truth for China is different from other countries these days.
 Any automated tool to do this kind of scanning should not have an
 assumption that IP or TCP connect scans and a full handshake with data
 will produce the same results.

 Right, that's an assumption that needs to be made explicit.  Want to help
 write the report, so that these things come over correctly?

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