[tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks

[Imre Jonk]

Hi nusenu,

On Sun, 2020-07-05 at 18:35 +0200, nusenu wrote:
> https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548

This was an interesting article, thanks for sharing. It's sad to read
that you and the anonymous Tor core member weren't heard on the bad-
relays list. Did you ever get a reply from a directory authority? I
would assume that the dir auths are very keen to discuss this subject.

> To prevent this from happening over and over again
> I'm proposing two simple but to some extend effective relay
> requirements 
> to make malicious relay operations more expensive, time consuming,
> less sustainable and more risky for such actors:
> 
> a) require a verified email address for the exit or guard relay flag.
> (automated verification, many relays)

Wouldn't that be a hurdle for a lot of relay operators? I can imagine
that many operators (of smaller relays) don't publish contact
information for privacy reasons. Of course, in your proposal that
information would only be shared with the directory authorities, but do
we have any numbers on how many relay operators are okay with this?

You mention that the current defenses are inadequate for protection
against slowly-added dispersed relays that are run by malicious actors.
Wouldn't introducing this requirement prevent some relay operators with
good intentions from serving exit or guard relays?

Furthermore, do we have any information on how much more difficult it
would become to perform a sybil attack if your proposal is implemented?
Assuming that this is something that can be somewhat accurately
measured.

> b) require a verified physical address for large operators (>=0.5%
> exit or guard probability)
> (manual verification, low number of operators). 
> It is not required that the address is public or stored after it got
> verified.
> For details see bellow [2].
> 
> 0.5% exit probability is currently about 500-600 Mbit/s of advertised
> bandwidth.

That seems reasonable. I currently co-run an exit relay that has just
under 0.1% probability and would be okay with sharing my physical
address with the directory authorities, especially if my probability
would be higher.

However, 0.5% seems like an arbitrary number to me. Can you provide
some background information on how you got to this percentage? Is there
maybe some way to calculate a malicious relay operator's
deanonymisation success rate?

> 
> Q: How many operators would be affected by the physical address
> verification requirement if we use 0.5% as a threshold?
> A: About 30 operators.
> 
> There are currently about 18 exit [3] and 12 guard operators that run
> >0.5% exit/guard capacity 
> if we ignore the fresh exit groups from 2020.
> Most exit operators (14 out of these 18) are organizations with
> public addresses or have their address published in WHOIS
> anyway.

Please don't assume that all big relay operators are happy with sharing
their physical address because most of them already do. Maybe we can
poll the big relay operators to find out if they are okay with this? (I
don't know if all of them are represented on this list)

Edit: looks like niftybunny is already on this.

> At the end of the upcoming blog post I'd like to give people some
> idea as to how much support this proposal has.

Great, I'm looking forward to this. It's a good thing to publicly
discuss proposals like these.

> Please let me know if you find this idea to limit attackers useful,
> especially if you are a long term relay operator,
> one of the 30 operators running >=0.5% exit/guard capacity, a Tor
> directory authority operator or part of The Torproject.

It is definitely an interesting idea, one that I have not thought of at
least. But I'm not sure if it would be effective at preventing what it
tries to prevent. Ultimately, the best solution for the sybil-attacks-
are-easy problem is simple: we need more bandwidth provided by relays
from operators with good intentions.

Imre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200705/1d3f8867/attachment.sig>