Hi,
A quick reminder to everyone on this list: this list is moderated.
Please keep your replies helpful and on topic.
> On 13 Feb 2020, at 22:05, zwiebeln <zwiebeln@xxxxxxxxx> wrote:
>
> depended on a network that is 21 percent controlled by a single person
> that you don't know?
>
> https://nusenu.github.io/OrNetStats/allexitfamilies
>
> I think we should start an open debate on that fact, best ending up with
> giving some recommendations. I am sure that question is relevant to
> torproject.org as well.
We've had similar questions a few times on this list.
The most common answer is:
"Let's encourage people to run more relays."
Perhaps you could run more relays?
Or ask for help improving your consensus weight?
The operator of those relays is on this list, asks questions, and
responds to emails. They've been helpful in the past.
So please ask questions in a way that assumes good faith:
https://en.wikipedia.org/wiki/Good_faith
You'll be more likely to get a helpful answer.
It's also important to keep network risks in perspective:
* 99% of relays run Linux, and a significant number of those are Debian
(or Ubuntu, or other derivatives)
https://metrics.torproject.org/platforms.html
* there is 1 bridge authority (100%), 6 bandwidth authorities (17%),
and 9 directory authorities (11%)
* the consensus algorithm tries to limit the risks of one directory
authority influencing large parts of the tor network, and manual
bridge distribution limits the impact of the bridge authority
* the largest ASes have:
* 23% of guards and 22% of middles (Hetzner)
* 16% of guards and 12% of middles (OVH)
* 10% if guards (Online)
* 20% of exits (J P McQ)
https://metrics.torproject.org/rs.html#aggregate/as
So it's not really helpful to single out a particular operator or
network.
As far as I recall, the most widespread security issue that's happened
to the network was the Debian OpenSSL bug:
https://www.debian.org/security/key-rollover/
There are all kinds of risks that happen when a large part of the
network has a similar setup:
* relay operator compromise
* AS operator compromise
* platform compromise
* observation of traffic via common network infrastructure
* network availability
* poor performance
* poor bandwidth weights
Tor relay consensus weights are determined by the bandwidth
authorities, so we might also be seeing:
* a bug in the bandwidth authority software (sbws or Torflow), or
* a majority of bandwidth authorities configured in a way that
concentrates bandwidth in particular areas.
I've opened a ticket in sbws to track this issue:
https://trac.torproject.org/projects/tor/ticket/33350
(Torflow is unmaintained, and we're planning to completely replace it
with sbws in 2020 or 2021.)
I'll also ask our new Network Health team to consider the risk of
large operators and large ASes. Hopefully they can recommend some
changes to the bandwidth authorities (or sbws maintainers).
But ultimately, if we doubled tor's exit bandwidth, this issue would
go away. That's the best solution to this problem.
Again, please keep your replies helpful and on topic.
T
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays