Opened 3 years ago

Last modified 15 months ago

#16671 new enhancement

Design a new Bridge Distributor for Tor Browser

Reported by: isis Owned by: isis
Priority: Medium Milestone:
Component: Obfuscation/BridgeDB Version:
Severity: Normal Keywords: bridgedb-dist, tor-browser-wants
Cc: sysrqb, mikeperry, brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

From recent discussions in developer meetings and on the mailing lists, it is planned that there should be some API/mechanism for Tor Browser to retrieve bridges from BridgeDB. , this will require a new Bridge Distributor.

Regardless of whether this mechanism is automated or interactive, if we follow BridgeDB's spec, and we allow wish for the logic controlling how Tor Browser users are handled to be separate (and thus more maintainable), then this will require a new Bridge Distributor, and we should probably start thinking about the threat model/security requirements, and behaviours, of the new Distributor. Some design questions we'll need to answer include:

  • Should all points on the Distributor's hashring be reachable at a given time (i.e., should there be some feasible way, at any given point in time, to receive any and every Bridge allocated to the Distributor)?
  • Or should the Distributor's hashring rotate per time period? Or should it have sub-hashrings which rotate in and out of commission?
  • Should it attempt to balance the distribution of clients to Bridges, so that a (few) Bridge(s) at a time aren't hit with tons of new clients?
  • Should it treat users coming from the domain front as separate from those coming from elsewhere? (Is is even possible for clients to come from elsewhere? Can clients use Tor to reach this distributor? Can Tor Browser connect directly to BridgeDB, not through the domain front? See #16650)
  • If we're going to do autoprobing, should it still give out a maximum of three Bridges per request? More? Less?

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by isis

Cc: mikeperry added

comment:2 in reply to:  description Changed 3 years ago by elypter

a few opinions

Replying to isis:

  • Should all points on the Distributor's hashring be reachable at a given time (i.e., should there be some feasible way, at any given point in time, to receive any and every Bridge allocated to the Distributor)?
  • Or should the Distributor's hashring rotate per time period? Or should it have sub-hashrings which rotate in and out of commission?

dont provide all bridges at the same time even for different ips. if an adversary is enumerating all available bridges for one time and they are blocked immediately then bridgedb would have a chance to react and not all bridges will be blocked from one second to the other so some people in a country will still be able to communicate.

  • Should it attempt to balance the distribution of clients to Bridges, so that a (few) Bridge(s) at a time aren't hit with tons of new clients?

rotation should be faster when more people who could need bridges are using tor. for example rotate faster during the afternoon and evening time in china.
ipranges from countries who need bridges should get more bridges assigned

  • Should it treat users coming from the domain front as separate from those coming from elsewhere? (Is is even possible for clients to come from elsewhere? Can clients use Tor to reach this distributor? Can Tor Browser connect directly to BridgeDB, not through the domain front? See #16650)

if the distributor detects access that is not possible to come from a normal user then its either an adversary or a developer. either hand out no bridges, fake bridges or a very small set of bridges.

  • If we're going to do autoprobing, should it still give out a maximum of three Bridges per request? More? Less?

even if its not impassable barrier there should at least be a captcha so an adversary at least has to do some coding or manual work. there should also be rate limiting. if there is a rate limit then it would be better to only give out 1 bridge at a smaller interval.
hand out wrong bridges when the captcha is wrong so an algorithm cannot learn.

comment:3 Changed 15 months ago by isis

Severity: Normal

Related: #22871
Required prerequisite work: #15967

comment:4 Changed 15 months ago by mcs

Cc: brade mcs added
Note: See TracTickets for help on using tickets.