How many of us do not have our own IP space and can already be verified by this? > On 5. Jul 2020, at 17:54, nusenu <nusenu-lists@xxxxxxxxxx> 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) > > 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. > > > 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@xxxxxxxxxxxxxxxxxxxxxxx 22.73 > Foundation for Applied Privacy 6.05 > John L. Ricketts, PhD <john AT quintex dot com> 5.6 > F3 Netze <abuse@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxxxx 0.52 > > 14 out of these 18 operators have their address already publicly listed because they are registered organizations or similar. > > >
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