[tor-bugs] #18329 [Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Feb 17 18:36:17 UTC 2016


#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
-------------------------+---------------------
 Reporter:  karsten      |          Owner:
     Type:  enhancement  |         Status:  new
 Priority:  Medium       |      Milestone:
Component:  Tor          |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:  tor-bridge   |  Actual Points:
Parent ID:               |         Points:
  Sponsor:               |
-------------------------+---------------------

Comment (by dcf):

 I completely forgot that we had a discussion on this topic back in 2014.
   https://lists.torproject.org/pipermail/tor-dev/2014-October/007610.html
 I'm trying to remember what caused me to bring it up. At the time, we were
 in the middle of [https://nymith.ch/active-probing/ active probing]
 research, and we definitely didn't want the public connecting to our
 honeypot bridges, so we set `PublishServerDescriptor 0`. I don't know why
 I would have cared about metrics for that experiment, though. Maybe it was
 some other reason.

 Somewhat related are #7349 and https://lists.torproject.org/pipermail/tor-
 dev/2014-December/008028.html. A bridge might only want at PT port exposed
 through BridgeDB, because the presence of an easily detectable ORPort
 connection could blow the cover of, say, obfs4 on the same IP address.

 The use case for this time is pretty narrow: testing whether censors
 scrape default bridges from the bundles, and how long it takes. The
 hypothesis that if a censor can scrape BridgeDB, then it can scrape
 bundles (therefore there is no reason to keep bundle bridges out of
 BridgeDB) is a reasonable one, but we can't assume it's true while running
 an experiment to test it. (It also would not surprise me if it is false:
 think of the times you unnecessarily elaborate engineering because you
 didn't adequately understand the problem; censors are not all world-class
 and they have these constraints too.) For this use case, I think the
 workaround of setting `PublishServerDescriptor 1` while firewalling closed
 the ORPort is good enough.

 My position is: all the Tor Browser default bridges should publish
 statistics, or else we are greatly undercounting users (the same goes for
 any bridge with a lot of users). Whether the Tor Browser default bridges
 ''also'' appear in BridgeDB is mostly immaterial, except in special cases
 like we're doing now. There are "default bridges" other than those in Tor
 Browser, for example those in Orbot; they don't have to be all the same or
 get burned at the same time. If we require all default bridges to be
 present in BridgeDB, and a censor is capable of scraping BridgeDB, then
 BridgeDB is a common weak link that will eventually get all the bridges
 blocked; whereas if they are not in BridgeDB, then it's as if we have
 different pools of bridges, the same way BridgeDB has smtp, http, etc.
 pools where the compromise of one doesn't lead to the compromise of
 another.

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


More information about the tor-bugs mailing list