[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: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.  And we don't know if the TCP test will fail for normal bridges
 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?

 I don't know.

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

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

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

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