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

[niftybunny]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200705/604b44cd/attachment.sig>