[tor-bugs] #6396 [BridgeDB]: Reachability tests for obfuscated bridges

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jun 25 05:15:31 UTC 2013


#6396: Reachability tests for obfuscated bridges
---------------------------+------------------------------------------------
 Reporter:  asn            |          Owner:  isis    
     Type:  task           |         Status:  accepted
 Priority:  major          |      Milestone:          
Component:  BridgeDB       |        Version:          
 Keywords:  pt tor-bridge  |         Parent:  #8615   
   Points:                 |   Actualpoints:          
---------------------------+------------------------------------------------
Changes (by isis):

  * status:  new => accepted
  * owner:  => isis


Comment:

 Replying to [comment:17 asn]:
 >
 > I understand this issue. Unfortunately, I don't know how to fix it
 easily. Looking at the chaos of #6414 and #5028, it seems that building a
 distributed bridge scanner is not easy to do and probably not worth
 spending our time on (BridgeDB has much more urgent tasks to be done).
 >
 > Furthermore, even if we fix this on the BridgeDB layer, the bridge
 authority will keep on doing direct reachability tests. This has been the
 case for years and it's public knowledge (#8 of
 https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-
 bridges) and it still has not been used by a censor.
 >
 > If we are still worrying about this attack vector, doing our
 reachability tests over Tor might make it a bit harder to harvest bridge
 addresses and it's also easy to do.
 >

 Yep. Agreed.

 If we get worried about exits collecting the addresses, we could also
 chain a bunch of bridges together by just sending RELAYEXTEND cells, then
 adding two public relays to the end of the chain to meet the default
 RefuseUnknownExit setting, and exiting to check.torproject.org or
 something else innocuous. But that is some pretty serious paranoia, and
 not necessary yet. :)

 > (To be clear, I also believe that in the future we should look into some
 kind of distributed bridge scanning, but at the moment it kind of looks
 like a luxury item when at the same time BridgeDB misses some essential
 features.)
 >
 > > I would suggest that a non-ooni version of hellais' script go into
 BridgeDB instead of going into ooni-probe, as it would fit this function
 precisely. Some minor amount of work would need to be done to add in the
 bits of Twisted which are covered by ooni-probe, so that hellais' bridget
 would work standalone.
 >
 > If Arturo's script is easy to be refactored to be standalone, I find it
 a reasonable plan. However, if making it standalone requires non-
 negligible engineering time, I would spend it somewhere else and instead
 just use OONI in BridgeDB.

 Looking into it right now. I'll report back in a bit with either a script
 or a problem.

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


More information about the tor-bugs mailing list