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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Wed Mar 14 09:02:55 UTC 2012


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

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

 Hrm. I think that full Tor handshakes are best all around - the question
 is more about how we transport the handshake - that is to say that a full
 obfu bridge test is the useful test for China today, not TCP or TLS - we
 already know the latter two fail almost all of the time.

 I do agree that a TCP scan is safer for China than a full handshake but
 I'm not convinced it is terribly useful for China for that very same
 reason. I do think one useful outcome of the TCP scan is that we might
 learn where other people have triggered an active probe that resulted in
 an IP block. I wonder though, do we know for sure that active scans put
 those IP addresses into a firewall forever? Or have active scans replaced
 that static block list?

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

 Ok. I think that if we exclude those, we'll have a set of bridges that
 have likely been harvested and blocked or just blocked by active probing.
 It's not clear how we'll know the difference with a TCP connection scan.

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

 I think the lower the number, the better a chance we'll get at refining
 these tests over a few hours - if we lose them all in on shot, we're sorta
 out of luck until they churn.

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

 I'm happy to look at the data but I don't know what such a report entails,
 I assume that's a different deliverable?

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


More information about the tor-bugs mailing list