Am So., 5. Juli 2020 um 18:36 Uhr schrieb nusenu nusenu-lists@riseup.net:
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-to...
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).
I would not be very happy to be required to give away personal identifying information even if it's a "trusted entity".
Even if Tor is focused on offering anonymity to its users and not necessarily to its relay operators a move towards this by an organisation that supports privacy wherever they can would seem like a strange idea to me.
I remember that i suggested the idea with an email based verification in one of my previous emails and i still think that would not be a bad idea but i think juristically it might be a difference if the torproject (or maybe even each of the authority operators itself) only have the ability to reject relays or if they even have the ability to decide who is allowed to join.
Your blog post talks about that you found relays doing something odd that the official Tor software is not able to do.
So if that's the only reason for this whole email then i don't see a reason for any of this because relays "doing something odd" should not be able to be part of the Tor network.
In your blog post you talk about malicious relays which as far as i understand are relays who are in the position for doing end-to-end correlation attacks.
Are these attacks really something to worry about in real life or is it just a fear because they are possible theoretically?
I mean even if a malicious entity is adding relays how big is the risk in real life that they can hurt you when they at least can not "do something odd" anymore?
Onion services for example are an answer for that.
Generally i think it's a rather strange move that the opinion changed to "let's cripple operators who want to contribute more" instead of trying to encourage more people to run relays so that the percentage of the other operators will decrease by itself.
The amount of Tor relays seems to have reached its peak (for now, maybe) so i think crippling the existing operators is not necessarily the best way to go and when someone wants to add more relays he should be able to do that without introducing a two-class system of verified and not verified operators.