[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18329 [Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs