Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#19728 closed task (fixed)

Pick, and deploy, a new bridge authority

Reported by: arma Owned by: isis
Priority: Immediate Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Critical Keywords: TorCoreTeam201608
Cc: Actual Points:
Parent ID: Points: 6
Reviewer: Sponsor:

Description (last modified by arma)

We are losing Tonga at the end of August (#19690). That means we should spin up a new bridge authority.

What are the criteria we should be considering, for the operator, location, etc of this bridge authority? To answer that, I think we should start by brainstorming all of the risks that we should consider.

So: what are we trusting the bridge authority for? Related, what does the bridge authority see? And what does an adversary watching the bridge authority see?

First, it sees the unscrubbed bridge data, i.e. the IP addresses, usage stats, fingerprints, etc of bridges. I think this is the same as what bridgedb sees, but more detailed than what onionoo serves. We rely on the bridge authority to have high security so bad people can't break in and steal the bridge addresses (that's number 7 on https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges).

Second, the bridge authority does bridge reachability tests. So somebody who watches its network connection gets to learn bridge addresses too. (Bridges use Tor, and encrypted begindir connections, to *publish* their descriptors to the bridge authority, so you can't learn about them that way.) This part is probably a design flaw, in that it's a shame we have centralized the reachability testing; but we don't have a better design for that currently, so it remains an issue here. (This is number eight on the blog post above.)

Third, it *used* to be the case, in the original design, that the bridge authority needs to have really high reliability and bandwidth. That requirement was because users were expected to go back to the bridge authority quite frequently, to see if their bridges have changed location. The original idea was that users would get n bridges, and over time k of them would move locations or something, and so long as at least 1 of the n remained working, the Tor client could automatically discover the new bridge locations by fetching updated bridge descriptors from Tonga. But we basically stopped building the bridge design before we got that part working, so it isn't really an issue here.

Fourth (added based on Sebastian's comment below), we are relying on the bridge authority to have a consistent IP address for a very long time, since bridges upload their descriptors using this address. That is, I think it is the case that changing its IP address is effectively the same as picking a new bridge authority?

What other constraints/risks/goals did I miss?

Child Tickets

TicketStatusOwnerSummaryComponent
#19937closedMerge isis patch [ticket#?] to 028 stableCore Tor/Tor
#19938closedstats on versions of Tor that bridges are runningMetrics/CollecTor

Change History (23)

comment:1 Changed 3 years ago by arma

Description: modified (diff)

comment:2 Changed 3 years ago by Sebastian

It's a benefit if the operator is one of the people already having access to the unscrubbed descriptors. It needs as stable an IP address as we can get it, because we have just one (and having more than one is a nice theory for later at this point).

comment:3 Changed 3 years ago by arma

Because of "Second", I am unexcited about putting the bridge authority under the nose of any intelligence agency. Wherever we put it, it's a gift to whoever's network it's on. So in that sense the *network* location is at least as important as the security of the system itself. If somebody can point us at a network location where no adversaries can watch, let us know. :) Otherwise, it's about choosing which adversary to stick it next to, and that is a crummy choice to have to make.

Because of "First", I think putting it nearby (in terms of trust) to bridgedb or the metrics archiver makes a lot of sense.

Sebastian makes a good point above that "location stability" is a key requirement for the bridge authority.

comment:4 Changed 3 years ago by Sebastian

Oh. You need ipv6. Are there still places without? Thought I'd mention it.

comment:5 Changed 3 years ago by arma

Description: modified (diff)

comment:6 in reply to:  2 Changed 3 years ago by arma

Replying to Sebastian:

It needs as stable an IP address as we can get it, because we have just one (and having more than one is a nice theory for later at this point).

Good one! I added that as "Fourth" above.

comment:7 Changed 3 years ago by s7r

I suggest adding something which will allow us some space for further moves: if the hardcoded IP address of the bridge authority is unreachable, fallback to the A and/or AAAA record (DNSSEC signed) for bridgeauth.torproject.org. It's not a fantastic fix but will at least make further migrations slightly easier. I guess we can assume that there will be bigger problems than the bridge authority to worry about in case something happens to torproject.org domain name.

comment:8 Changed 3 years ago by mo

I never proposed to run an authority or even a bridge authority because I have access to too many exits already, but we (Zwiebelfreunde) do have currently unused IPv4/IPv6 PI space that should be pretty stable that we could hand over to someone else, if this helps.

comment:9 Changed 3 years ago by s7r

Count me in too for this, if no better solutions appear. I could arrange something, I have 2 places possible candidates which should fulfill the requirements.

comment:10 in reply to:  4 Changed 3 years ago by arma

Replying to Sebastian:

Oh. You need ipv6.

I don't think you need ipv6. *Maybe* you need it for the ipv6 reachability tests, but I bet everything would work just fine if the bridge authority just declares that it doesn't know how to do ipv6 reachability testing.

But you don't, for example, need to be reachable on an ipv6 address, since everybody interacts with the bridge authority via Tor.

comment:11 Changed 3 years ago by Sebastian

You're the best kind of right. Still I reserve to question the sanity of any hosting place that doesn't provide ipv6. But I'm fine not including it in the criteria list you're making in the description ;)

comment:12 Changed 3 years ago by lakridserne

While IPv6 might not be strictly required it *should* really be there for the bridge authority in my opinion. While it's not as widely deployed consumer wise as I'd like, IPv6 is possible to get in most data centers - and I'd really hate that some node was picked where we'll then have to switch again in a few years (hopefully) when we then really need IPv6.

comment:13 Changed 3 years ago by BrassHornComms

FWIW I am more than happy to host this ( https://mobile.twitter.com/BrassHornComms/status/755382167706955776 ) BrassHorn announces IPv6 and IPv4 via its own ASN (AS28715)

Recently some of my relays were added to the fallback dir list ( https://mobile.twitter.com/BrassHornComms/status/728630564706603008 ) which I hope goes someway to showing the reliability of my network.

comment:14 in reply to:  13 ; Changed 3 years ago by teor

Replying to BrassHornComms:

FWIW I am more than happy to host this ( https://mobile.twitter.com/BrassHornComms/status/755382167706955776 ) BrassHorn announces IPv6 and IPv4 via its own ASN (AS28715)

Recently some of my relays were added to the fallback dir list ( https://mobile.twitter.com/BrassHornComms/status/728630564706603008 ) which I hope goes someway to showing the reliability of my network.

I just wanted to clarify here - the list you linked to in that tweet was an opt-in whitelist. Anyone could opt-in, and we specifically contacted operators of stable relays with at least a few megabits of bandwidth.

Then we ran a script that ranked the opt-in list of relays by bandwidth, checked them for reliability, and selected the top 100. That produced the 0.2.8.5-rc list of fallback directories:
https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc

The Brass Horn relays aren't on the fallback list for 0.2.8.5-rc, because the bandwidth cutoff was ~6 Mbps, and the Brass Horn relays that were opted in were below that.

comment:15 Changed 3 years ago by teor

For the record, the bridge authority details that we hard-code in the Tor source code are:

"Tonga orport=443 bridge "
"82.94.251.203:80 4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D",

The bridge authority needs a stable IPv4, ports, and key.
(The key isn't mentioned in the ticket description - it's implicit, but it does mean that we should pick one operator with key access, and stick with them.)

There is no reason for us to hard-code an IPv6 address, as nothing needs to contact the bridge authority on IPv6.

comment:16 in reply to:  14 Changed 3 years ago by BrassHornComms

Replying to teor:

The Brass Horn relays aren't on the fallback list for 0.2.8.5-rc, because the bandwidth cutoff was ~6 Mbps, and the Brass Horn relays that were opted in were below that.

Ah, well once I've finished getting IXP peering sorted bandwidth will become a lot cheaper and will allow for a significant increase in relay speeds!

comment:17 Changed 3 years ago by isis

Points: 6
Priority: MediumImmediate
Severity: NormalCritical
Status: newneeds_review

Patch in my bug19728 branch.

comment:18 Changed 3 years ago by nickm

Added a changes file, and cherry-picked to 0.2.7 and forward.

comment:19 Changed 3 years ago by nickm

Keywords: TorCoreTeam201608 added

comment:20 Changed 3 years ago by isis

Owner: set to isis
Status: needs_reviewassigned

comment:21 Changed 3 years ago by isis

Resolution: fixed
Status: assignedclosed

I closed child tickets #19937 and #19938. This task is finished as well.

comment:22 Changed 2 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.4.x-final

comment:23 Changed 2 years ago by nickm

backported to 0.2.4

Note: See TracTickets for help on using tickets.