[tor-relays] Would you place your secrets or in worst case make your life
zwiebeln
zwiebeln at online.de
Mon Feb 17 12:43:44 UTC 2020
There is only a small path between moderation and censorship – to get my message released after four days is close to…
Your answer Theo is rather technical and doesn't apply really on the underlying question:
„Would you place your secrets or in worst case make your life depended on a network that is 21 percent controlled by a single person that you don't know?“
Your assumption: „But ultimately, if we doubled tor's exit bandwidth, this issue would go away. That's the best solution to this problem.“ - is wrong. The Exit only https://metrics.torproject.org/bandwidth-flags.html?start=2017-11-19&end=2020-02-17 has more than doubled in the last two years – while the exit probability of this single person decupled.
„Perhaps you could run more relays?“ - I am with the project now for more than three years an do run a exit probability somewhere close to 2 percent, that i don't like to increase, because i think it is a more than healthy fraction for a singe person – so why do you insinuate, my question is not in a „good faith“?
I hope more people do come on board of this discussion now!
Paul
On 17.02.20 02:53, teor wrote:
> 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 at online.de> 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
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
More information about the tor-relays
mailing list