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

 Replying to [comment:43 karsten]:
 > Replying to [comment:42 ioerror]:
 > > 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.
 >
 > Testing a normal bridge and testing an obfsproxy bridge are two
 different things.

 Sure and they're both bridges.

 > And we don't know if the TCP test will fail for normal bridges almost
 all of the time.
 >

 Ah, to clarify, I mean _if_ the IP is known/blocked or an active probe is
 confirms it in real time, we know those two issues well enough. The
 problem scope is pretty well defined for those and we think currently that
 obfu bridges are not yet in the protocol detection bucket but rather only
 in the IP harvesting/known/blocked bucket.

 > > 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?
 >
 > I don't know.
 >

 Me either.

 > > 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.
 >
 > It's a start.  It's not supposed to be perfect.

 Sure, I think small batches are probably best at first.

 >
 > > > 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.
 >
 > I don't expect us to have time for another test after this one, so these
 125 bridges will be it.
 >

 I'd suggest that for such a scan - the first test should be something like
 a dozen bridges, the second the same dozen and so on. If you use all 125
 at once, I wouldn't be surprised to learn that the next hour results in
 all of them being blocked with no more bridges to experiment with or use
 for the day.

 > > > 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?
 >
 > Ah, the "report" would simply summarize what we found in this
 deliverable, so that the sponsor doesn't have to read lengthy Trac
 tickets.  I'd simply start a LaTeX article document, but it could also be
 a blog post.  Something we can finish by tomorrow.

 Well, it's 3am PST now on the 15th, so I think we'll need some data before
 anyone can commit to writing up an analysis of that data. I'm happy to try
 to understand the data and to contribute to whatever write up happens. I'm
 going to sleep for a bit and then check back when I wake up.

 Good luck with the data collection!

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