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

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

 It seems like such an automated scan should contain special cases for
 countries with network censorship systems that are as advanced as China.

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

 I'd expect that things would run rather smoothly from Germany, yes.

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

 For a TCP connection scan or an actual bridge handshake, I predict we'll
 have totally different results for those above questions. If it's just a
 TCP connection, I'm not convinced the data will be the full picture, if
 it's the full handshake, I suspect it will result in blocking. We should
 be aware that such a scan may result in blocking and only use a pool of
 addresses we're OK with losing, probably where there is no intersection
 with obfu bridges.

 > Maybe we should run a third scan from another country.  How about .ru?
 Do we know if bridges are blocked from .ru?

 I think the Perfect Privacy VPN service has some servers in Russia and
 many others. I don't think Russia has blocked any bridges though.

 >And do we know whether a simple TCP scan with a timeout of 20 seconds
 will give us reliable information which bridges are reachable?
 >

 I'm not convinced that this is actually a useful test because of the
 different kinds of blocking at play. In Syria we found Bluecoat devices
 that would tear down a TCP connection only if a Tor client and a Tor
 bridge were speaking TLS; normal OpenSSL s_client did not have the same
 the same distinguishers with the same Tor bridge. If we're not doing a
 real TLS handshake, I think we only learn about IP blocking but not about
 actual Tor bridge reachability. That's useful info too but not actually
 giving us real data on bridges being reachable when a network is
 dynamically censoring by protocol, rather than IP.

 Obviously as arma points out, a full Tor handshake in China might not be
 the best idea, still, I bet we learn more ground truth with a real test
 and not a simulated test, given what we know about China these days.

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

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

 Ok.

 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.

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