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

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

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

 Replying to [comment:46 ioerror]:
 > Replying to [comment:45 karsten]:
 > > We ran the first scans from a node in .cn today.  The scan had two
 phases: first, we scanned 20 bridges twice with a delay of one hour to see
 whether scanning affects bridge reachability in any way; second, we
 scanned 100 bridges (10 of which were already contained in the previous
 phase) to have a larger sample.  All bridges were taken from the HTTPS
 bucket.
 > >
 > > In the first phase, only 2 out of 20 bridges were found as reachable.
 One hour later, the same 2 bridges and another bridge were found as
 reachable.  We concluded that the scan didn't lead to bridges being
 blocked and continued with the second phase.
 > >
 > > In the second phase, 14 out of 100 bridges were found as reachable.
 From the 86 unreachable bridges we removed 6 bridges that were not found
 as reachable by Tonga, either.  That leaves us with 80 bridges that Tonga
 found to be running and the scan found to be unreachable.  Reasons for
 bridges being unreachable were: 77 x connection timed out, 1 x connection
 refused, and 2 x no route to host.
 > >
 > > A manual analysis of the bridge usage statistics reported by the 14
 reachable bridges confirms that these bridges are actually reachable from
 .cn: 1 bridge reported 24 connections from .cn, 5 bridges reported 16
 connections, 6 bridges reported 8 connections, and 2 bridges didn't report
 country statistics.  The bridge usage statistics reported by the 80
 presumably blocked bridges have not been analyzed.
 > >
 > > What else should we look at in the results?
 >
 > We should know the network from where the scans were performed - it is
 thought that a few large telecoms do DPI, did we try from one of those? Or
 if it makes sense and is accurate, we should simply say "we did not try it
 from the known networks that filter" or something similar.

 I scanned from one of the hosts I had access to in PlanetLab. Would have
 to dig around if you want to know anything about the network the server is
 on.

 > > And what are the next steps towards "some sort of automated ground
 truth of bridge reachability from some countries" that we can take in,
 say, the next week?
 >
 > I think we'd need to automate these scans - can one simply toss them in
 a cron job and send the results somewhere to be processed? It seems like
 the process is pretty manual at this point, isn't it?

 Yes, that's easy to do.

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