Opened 4 years ago

Last modified 17 months ago

#13727 needs_review defect

BridgeDB should not distribute Tor Browser's default bridges

Reported by: isis Owned by: isis
Priority: Medium Milestone:
Component: Obfuscation/BridgeDB Version:
Severity: Normal Keywords: bridgedb-dist, tbb-bridges
Cc: isis, rransom, sysrqb, mikeperry, GeKo, yawning Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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 (6)

comment:1 Changed 4 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 4 years ago by yawning

Cc: yawning added

comment:3 Changed 21 months 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 21 months 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 18 months 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 17 months 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.

Note: See TracTickets for help on using tickets.