Opened 6 years ago

Closed 4 months ago

#13727 closed defect (fixed)

BridgeDB should not distribute Tor Browser's default bridges

Reported by: isis Owned by: phw
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Normal Keywords: bridgedb-dist, tbb-bridges, anti-censorship-roadmap-2020Q1, s30-o23a1
Cc: isis, rransom, sysrqb, mikeperry, GeKo, yawning, phw Actual Points: 0.4
Parent ID: #31280 Points: 2
Reviewer: Sponsor: Sponsor30-must

Description

From #13504, we started distributing, in Tor Browser as the sets of 'default' bridges, only bridges which report their descriptors to the BridgeAuthority, causing those descriptors to eventually be sent through BridgeDB to the Metrics servers. This was done to obtain more accurate Metrics on bridge usage, since it is believed that most bridge users are currently using the default bridges.

Robert Ransom points out that we don't want BridgeDB to distribute these default Tor Browser bridges. The reasons are similar to why we don't want to initialise/use multiple types of PTs at the same time in Tor Browser: Using a TB-default bridge, presumedly mixed in with other non-TB-default bridges obtained from BridgeDB, would signal to anyone watching for use of the TB-default bridges that the other addresses are Tor bridges, thus potentially endangering:

  1. the user, Alice, who was accidentally given the TB-default bridge by BridgeDB, because she may now find that all her bridges are suddenly blocked,
  2. Alice's other bridges, which are at increased risk of being blocked by whoever is watching Alice,
  3. and the other users of Alice's other bridges.

Child Tickets

Change History (25)

comment:1 Changed 6 years ago by isis

Status: newneeds_information

The technical implementation of this could be as simple/kludgey as creating a list of fingerprints of all bridges which have ever been TB-default bridges, and, should BridgeDB come across one of these fingerprints either while parsing or distributing, skip it.

The nicer, but more difficult, way to do this seems to be to implement something like #4026 and create a torbrowser bridge pool in BridgeDB which is never distributed, or a little-t tor modification to add a BridgeDistribution [https|email|tbdefault|any|none] line to server-descriptors as described in #13504:

Replying to isis:

[…]

Additionally, if bridge operators wish to give us metrics but are firmly against their bridges being distributed by BridgeDB, I can either:

  1. Create a torbrowser bridge pool in BridgeDB, which is never distributed.

This would only be a short-term doesn't-require-little-t-tor-patches hack. I don't really want to do this. However, if the bridge operators for Tor Browser bundle bridges really don't want to be distributed by BridgeDB, I am willing to do it.

  1. Add a torrc option, BridgeDistribution [https|email|any|none], as described on the mailing list and BridgeDB patches to disable distribution for bridges whose descriptors say BridgeDistribution none.

This would allow bridge operators to provide metrics without being publicly distributed by BridgeDB, and would likely only effect bridges running tor-0.2.6.x.

The default would be BridgeDistribution any, which would allow BridgeDB to choose how your bridge is distributed.

Using BridgeDistribution [https|email] would allow a bridge operator to override BridgeDB's decision.

Using BridgeDistribution none would instruct BridgeDB to either toss out your bridge's descriptor rather than putting them into the databases (or adding them to the 'unallocated' pool, depending on how we wish to implement this).



So, now we should probably decide which of these options (or others that someone else comes up with) that we want to do.

comment:2 Changed 6 years ago by yawning

Cc: yawning added

comment:3 Changed 4 years ago by dcf

Severity: Normal

Our current workaround for this is to ask the operators of default bridges to block their ORPort with a firewall, so the bridge isn't considered live by the bridge authority. Most of the current default obfs4 bridges are configured this way. Having an open ORPort can only be a liability for an obfs4 bridge; it creates the possibility that someone will connect to the ORPort using vanilla Tor, get DPIed, and burn the whole IP address (see also #7349).

comment:4 Changed 4 years ago by dcf

See also discussion at the related #18329. I thought about closing that one as a duplicate of this one, but decided not to because nickm had set a milestone on it.

comment:5 Changed 4 years ago by arma

I put a proposed branch on #18329.

Once that branch gets merged, then one way forward here would be for (1) BridgeDB to learn how to look at the new bridge-distribution-request lines in bridge descriptors, and (2) the default bridges, when they update to a new enough version, should set that line in their torrc, and optionally drop the "firewall their ORPort" kludge if they want.

comment:6 Changed 4 years ago by isis

Status: needs_informationneeds_review

This ticket should be fixed once #18329 and #21177 are done and merged. After that, we'll just need to convince the operators of the default bridges to add a "BridgeDistribution none" option to their torrcs.

comment:7 Changed 19 months ago by gaba

Owner: isis deleted
Points: 2
Sponsor: Sponsor19
Status: needs_reviewassigned

comment:8 Changed 17 months ago by phw

Given that #18329 and #21177 are now implemented, it's time to contact our default bridge operators. Do we have a list of contact information?

comment:9 Changed 17 months ago by phw

Cc: phw added

comment:10 Changed 15 months ago by gaba

Keywords: ex-sponsor-19 added

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

comment:11 Changed 14 months ago by phw

Sponsor: Sponsor19Sponsor30-must

Moving from Sponsor 19 to Sponsor 30.

comment:12 Changed 13 months ago by gaba

Keywords: anti-censorship-roadmap-september added; ex-sponsor-19 removed

comment:13 Changed 12 months ago by phw

Parent ID: #31268

comment:14 Changed 12 months ago by phw

Parent ID: #31268#31280

comment:15 Changed 12 months ago by pili

Parent ID: #31280#31349

comment:16 Changed 12 months ago by pili

Parent ID: #31349#31280

comment:17 Changed 11 months ago by phw

Here's where we're at: All default bridges except noisebridge01 have either firewalled their OR port or set BridgeDistribution none. Despite repeated emails, we haven't managed to get in touch with someone who manages noisebridge01.

For some reason, the default bridge FB70B257C162BF1038CA669D568D76F5B7F0BABB also shows up in BridgeDB's assignments.log file even though it set BridgeDistribution none. I wonder if this is a bug or if I'm misunderstanding something.

comment:18 Changed 10 months ago by gaba

Keywords: s30-o23a1 added

comment:19 in reply to:  17 Changed 8 months ago by phw

Replying to phw:

Here's where we're at: All default bridges except noisebridge01 have either firewalled their OR port or set BridgeDistribution none. Despite repeated emails, we haven't managed to get in touch with someone who manages noisebridge01.


I just sent an email to aestetix, the last person on noisebridge's list of tor admins. Andy, Patrick, Ben, and Leif unfortunately no longer have access.

For some reason, the default bridge FB70B257C162BF1038CA669D568D76F5B7F0BABB also shows up in BridgeDB's assignments.log file even though it set BridgeDistribution none. I wonder if this is a bug or if I'm misunderstanding something.


Ah, it turns out that this machine runs two bridges: a default bridge on port 80 and a normal bridge on port 443, both using the same fingerprint.

comment:20 Changed 6 months ago by gaba

Keywords: anti-censorship-roadmap-2020Q1 added; anti-censorship-roadmap-september removed

comment:21 Changed 6 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

comment:22 Changed 5 months ago by phw

I just filed #33630 to retire noisebridge01, our only default bridge which is still distributed by BridgeDB. Once that ticket is closed, we can close this one too.

While making sure that all remaining default bridges aren't distributed by BridgeDB, I noticed that cymrubridge02 and smallerRichard are in the HTTPS bucket despite having set BridgeDistribution none. Turns out this is a BridgeDB bug and I filed #33631 to get it fixed.

comment:23 Changed 4 months ago by phw

#33631 is now fixed, and both cymbrubridge02 and smallerRichard are no longer distributed by BridgeDB. That leaves noisebridge01 as the only bridge that's still distributed. Let's close this ticket once #33630 is fixed.

comment:24 Changed 4 months ago by phw

Owner: set to phw
Status: newassigned

comment:25 Changed 4 months ago by phw

Actual Points: 0.4
Resolution: fixed
Status: assignedclosed

Thanks to our applications team, noisebridge01 is no longer part of Tor Browser (#33630), so we're finally able to close this ticket.

For what it's worth, I was introduced to Steve Phillips from noisebridge who may be able to set up a new bridge at noisebridge and act as its maintainer.

Note: See TracTickets for help on using tickets.