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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:          
---------------------------+------------------------------------------------

Comment(by asn):

 Replying to [comment:18 isis]:
 > 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.

 Hm. Any news on this one?

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