Opened 4 months ago

Last modified 2 months ago

#26778 new defect

Enable supporting multiple bridge authorities

Reported by: chelseakomlo Owned by:
Priority: Medium Milestone: Tor: unspecified
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 (7)

comment:1 Changed 4 months 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 4 months ago by nickm

Keywords: needs-testing? needs-proposal? added

comment:3 in reply to:  1 ; Changed 4 months 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.

comment:4 Changed 4 months ago by dgoulet

Milestone: Tor: unspecified

comment:5 Changed 4 months ago by gman999

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.

I thought the data was being *pushed* by the bridge authority, not pulled.

Ultimately, if I'm reading this right, it's:

  • a single bridge authority, which lessens opportunity for bridge discovery, yet becomes a single point of failure.
  • multiple bridge authorities, with increases chance of bridge discovery, but decentralized and more resilient.

Maybe reworking through the threat model on bridge discovery and past experiences could be worthwhile to make a more informed decision on this?

Clearly FDE and physical security become a requirement, and not a flavor.

comment:6 in reply to:  5 Changed 4 months ago by chelseakomlo

Replying to gman999:

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.

I thought the data was being *pushed* by the bridge authority, not pulled.

The bridge authority pushes data to BridgeDB, but bridges themselves push data to the bridge authority, iiuc.


Ultimately, if I'm reading this right, it's:

  • a single bridge authority, which lessens opportunity for bridge discovery, yet becomes a single point of failure.

I would add a single bridge authority increases probability for single point of failure. This could have any number of causes- maybe the plug is pulled on the server, the operator gets run over by a bus (hopefully not), or the server is DDOSed/attacked/etc. Regardless, having some spread in case of failure, IMO, would be ideal.


  • multiple bridge authorities, with increases chance of bridge discovery, but decentralized and more resilient.

I'm not sure I understand how multiple bridge authorities increases the chance of bridge discovery. If an adversary can discover/query one bridge authority, how does this limit bridge discovery as opposed to an adversary being able to discover/query multiple authorities? As I understand, we want to minimize the number of entities which hold the complete list of bridges as holding this data in itself is risky, but adding more authorities shouldn't make bridges more discoverable to external entities (as I understand, please correct me if I'm wrong).

Maybe reworking through the threat model on bridge discovery and past experiences could be worthwhile to make a more informed decision on this?

That sounds good to me, I would be interested to hear about past experiences as well.

comment:7 in reply to:  3 Changed 2 months ago by arma

Replying to chelseakomlo:

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.

Check out the router_upload_dir_desc_to_dirservers() function. It's the same function that relays use to publish their descriptor to v3 dir auths.

It calls directory_post_to_dirservers() which loops over

  SMARTLIST_FOREACH_BEGIN(dirservers, dir_server_t *, ds) {

calling directory_initiate_command_routerstatus() for each authority that is appropriate for an upload attempt.

Note: See TracTickets for help on using tickets.