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

[Tor Bug Tracker & Wiki]

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

Comment(by asn):

 Replying to [comment:16 isis]:
 > Replying to [comment:13 sysrqb]:
 > > It might almost be better to create a file of unreachable/non-
 listening bridges. As far as I can think (right this second), with the
 current script, BridgeDB would have to parse this file occasionally (on
 some sort of schedule), determine which of the bridges are currently in a
 ring, add any bridges as unallocated if they are new, compute the non-
 intersecting set of bridges it currently has in its rings that that were
 not in the file (could not be reached) and remove them - that last step
 being fairly expensive.
 > >
 >
 > As far as I know, BridgeDB currently does this, if you look here:
 https://gitweb.torproject.org/bridgedb.git/blob/HEAD:/lib/bridgedb/Bucket.py#l220
 >
 > Though, I do not know where it is determining these bridges. (or if it
 is able to)
 >
 > Replying to [comment:15 asn]:
 > >  Replying to sysrqb:
 > > >     (Not having looked at the current version of bridget: )
 > > >
 > > >     1) From which host do we want to run it? From the same host as
 BridgeDB? Can we assume, initially, that we're not extremely bothered by
 the fact that a few bridges may be blocked because we probe them and they
 are within a censoring zone?
 > >
 > > Running the tests from BridgeDB seems easier to deploy. In the future,
 we might want to consider some kind of decentralized system (similar to
 #6414), but I wouldn't worry too much about this in the beginning.
 >
 > hellais' version of bridget.py should be suitable for running ''from''
 BridgeDB. A distinction was not made in much of the discussion for #6414,
 and determining if a given bridge is blocked from a ''specific'' country
 is much more difficult than determining if it the host is online or not
 from BridgeDB. From BridgeDB, if we take as an assumption that BridgeDB is
 not under surveillance, is is simple to test if the bridge is up. hellais'
 script will do that, though when I tested it, it did not run at that
 commit -- I do not recall if this was an error in ooni-probe, perhaps due
 to all the recent changes for director.py, or if it was an error in
 bridget.py.
 >
 > Note, FWIW, my apprehension over merging hellais' script as "bridget" is
 largely due to the above confusion, as running it from a given country
 ''might'' tell you if the bridge is blocked from your country -- though it
 would likely get the bridge blocked if it was not already. Hence, putting
 it into ooni-probe labelled as a "bridge reachability test" would be an
 extreme misnomer, as it would function more as a "bridge blocker" in
 censoring countries.
 >

 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.

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

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