Opened 3 days ago

Last modified 2 days ago

#26778 new defect

Enable supporting multiple bridge authorities

Reported by: chelseakomlo Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-bridges needs-testing? needs-proposal?
Cc: dgoulet, sysrqb Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

BridgeDB already supports multiple bridge authorities. To add an additional bridge authority, it needs to be added to the bridgedb config in the BRIDGE_AUTHORITY_DIRECTORIES list.

A bridge should be able to select a bridge authority from the list of authorities, where multiple bridge authorities can be represented, and try one at a time until it is able to successfully upload its descriptor.

Note: This feature might already exist in tor, so auditing the code to check first would be useful.

Child Tickets

Change History (3)

comment:1 Changed 3 days ago by arma

My first thought here is that I believe it should work right now for Tor to have two bridge auths, and bridges will simply publish their bridge descriptor to both of them. (And by "two" I mean "n".)

Then the bridge auths become redundant, i.e. one of them can catch fire but the pipeline still gets the bridges through.

One downside of that style of redundancy is increased surface area: that is, there is one more place in the world that has the list of bridges and that is making connections to all the bridges.

But I think it will take much more design to produce a "distributed" bridge authority that actually has reduced surface area in practice. (For example, if each bridge alternates each day which authority it sends its descriptor to, are we really gaining that much?)

Also, in the original bridge authority design, which still sort of works in the code right now, clients would reach out to the bridge authority directly (or via a Tor circuit using an existing working bridge) to fetch new descriptors for bridges that moved addresses. So if we want to keep that design possible for the future, we need bridges to *deterministically* assign themselves to bridge authorities, such that clients can predict the assignment too. See #2473. Maybe we want to close off that design because it's more trouble than it's worth, but also maybe not.

tl;dr I think what you want is already in the code base, so long as you're ok with a slight tweak to what you want. :)

comment:2 Changed 2 days ago by nickm

Keywords: needs-testing? needs-proposal? added

comment:3 in reply to:  1 Changed 2 days ago by chelseakomlo

Replying to arma:

My first thought here is that I believe it should work right now for Tor to have two bridge auths, and bridges will simply publish their bridge descriptor to both of them. (And by "two" I mean "n".)

Ok, that is good to hear. The main purpose of this is to ensure that tor can have more than one bridge authority.

Then the bridge auths become redundant, i.e. one of them can catch fire but the pipeline still gets the bridges through.

One downside of that style of redundancy is increased surface area: that is, there is one more place in the world that has the list of bridges and that is making connections to all the bridges.

But I think it will take much more design to produce a "distributed" bridge authority that actually has reduced surface area in practice. (For example, if each bridge alternates each day which authority it sends its descriptor to, are we really gaining that much?)

What is the risk of only sending it to the first authority that accepts the descriptor (from a authority chosen at random)? As BridgeDB is the point which takes the union of all descriptors, I would think relays uploading descriptors could load balance across available authorities.

But in practice it might not matter whether the bridge sends the descriptor to n authorities or 1, if n=2 or even if n=5.

Also, in the original bridge authority design, which still sort of works in the code right now, clients would reach out to the bridge authority directly (or via a Tor circuit using an existing working bridge) to fetch new descriptors for bridges that moved addresses. So if we want to keep that design possible for the future, we need bridges to *deterministically* assign themselves to bridge authorities, such that clients can predict the assignment too. See #2473. Maybe we want to close off that design because it's more trouble than it's worth, but also maybe not.

As I understand, there is a proposal where BridgeDB becomes distributed https://gitweb.torproject.org/torspec.git/tree/proposals/226-bridgedb-database-improvements.txt to mitigate against single points of failure cases.

What is the benefit of clients reaching out to authorities directly for bridge assignments, as opposed to BridgeDB being the single point where clients fetch bridges?

tl;dr I think what you want is already in the code base, so long as you're ok with a slight tweak to what you want. :)

Mainly I wanted to ensure that today more than one bridge authority can exist, so it is good that this can already happen.

If you can point me to where the "bridge uploads its descriptor to all bridge authorities" happens in the code, that would be helpful, I wanted to dig into this a bit more.

Note: See TracTickets for help on using tickets.