On Sun, 5 Jul 2020 at 17:36, nusenu <nusenu-li...@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-cont...@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 <ab...@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 > t...@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-opera...@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@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays