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

Sun Jul 5 20:51:27 UTC 2020

On Sun, 5 Jul 2020 at 17:36, nusenu <nusenu-lists at riseup.net> wrote:
>
> Hi,
>
> I'm currently writing a follow-up blog post to [1] about a large scale malicious tor exit relay operator
> that did run more than 23% of the Tor network's exit capacity (May 2020) before (some) of it got reported to the bad-relays team and
> subsequently removed from the network by the Tor directory authorities.
> After the initial removal the malicious actor quickly restored its activities and
> was back at >20% of the Tor network's exit capacity within weeks (June 2020).
>
> [1] https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548
>
> 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)

free email addresses are cheap, but I guess it would give another
correlation if they all use the same free email provider.

> 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.

I am not convinced it would help large scale attacks.
Running 50 relays is not much and it each was providing 0.49% of
capacity that would give them 24.5%...
I would expect that an attacker would create more relays than that and
unless there is a good way to find out this is a single entity, they
will all be well below 0.5%

> 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.
>
> At the end of the upcoming blog post I'd like to give people some idea as to how much support this proposal has.
>
> 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.
>
>
> thanks for your support to fight malicious tor relays!
> nusenu
> --
> https://mastodon.social/@nusenu
>
>
> [2]
> Physical address verification procedure could look like this:
>
> The Torproject publishes a central registry of trusted entities that agreed to verify addresses of large scale operators.
>
> The registry is broken down by area so no central entity needs to see all addresses or is in the position to block all submissions.
> (even though the number of physical address verifications are expected be stay bellow 50 for the time being).
>
> Examples could be:
>
> Riseup.net:  US, ...
> Chaos Computer Club (CCC) :  DE, ...
> DFRI: SE, ...
>
> (these organizations host Tor directory authorities)
>
>
> - Relay operators that would like to run more than 0.5% guard/exit fraction select their respective area and contact the entity to
> initiate verification.
>
> - before sending an address verification request the operator verifies that they meet the following requirements:
>   - the oldest relay is not younger than two months (https://community.torproject.org/relay/community-resources/swag/ )
>   - all relays have a proper MyFamily configuration
>   - relays include the verified email address and PGP key fingerprint in the relay's ContactInfo
>   - at least one of their relays gained the exit or guard flag
>   - they have a sustained bandwidth usage of at least 100 Mbit/s (accumulated)
>   - intention to run the capacity for at least 4 months
>
> - upon receiving a request the above requirements are verified by the verification entity in addition to:
>   - relay(s) are currently running
>   - the address is in the entity's area
>
> - a random string is generated by the address verification entity and send with the welcome tshirt (if requested) to the operator
>
> - after sending the token the address is deleted
>
> - upon receiving the random string the operator sends it back via email to the verification entity
> while signing the email with the PGP key mentioned in the relays ContactInfo
>
> - the verification entity compares the received string with the generated and mailed string
>
> - if the string matches the entity sends the relay fingerprint to the directory authority list to unlock the cap for the operator
>
> After this one-time procedure the operator can add more relays as long as they are in the same family as the approved relay (no new verification needed).
>
>
> [3]
>
> exit operators running >=0.5% of exit probability
> without exit groups from 2020
> (onionoo data as of 2020-07-03)
>
> abuse-contact at to-surf-and-protect.net                   22.73
> Foundation for Applied Privacy                          6.05
> John L. Ricketts, PhD <john AT quintex dot com>         5.6
> F3 Netze <abuse at f3netze.de>                             5.47
> https://www.torservers.net                              3.89
> Nicholas Merrill <nick AT calyx dot com>                2.48
> https://www.digitale-gesellschaft.ch/abuse/             1.74
> Accessnow.org <abuse .AT. accessnow .DOT. org>          1.71
> Hart voor Internetvrijheid                              1.63
> <zwiebeln at online de>                                 1.44
> TNinja <abuse-team at tor dot ninja>                    1.43
> tech at emeraldonion.org                                   1.31
> Frenn vun der Enn FVDE                                  1
> https://www.artikel5ev.de/torcontact/                   0.74
> Nos oignons                                             0.71
> tor-abuse<at>mailbox<dot>org                            0.67
> abuse-node49 AT posteo DOT de                           0.57
> tor-operator at privateinternetaccess.com                  0.52
>
> 14 out of these 18 operators have their address already publicly listed because they are registered organizations or similar.
>
>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays