[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #19728 [Core Tor/Tor]: Pick, and deploy, a new bridge authority
#19728: Pick, and deploy, a new bridge authority
--------------------------+------------------------------------
Reporter: arma | Owner:
Type: task | Status: new
Priority: Medium | Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Description changed by arma:
Old description:
> 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.
>
> 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.
>
> What other constraints/risks/goals did I miss?
New description:
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.
What other constraints/risks/goals did I miss?
--
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19728#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs