[tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
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-cont...@to-surf-and-protect.net 22.73 Foundation for Applied Privacy 6.05 John L. Ricketts, PhD 5.6 F3 Netze 5.47 https://www.torservers.net 3.89 Nicholas Merrill 2.48 https://www.digitale-gesellschaft.ch/abuse/ 1.74 Accessnow.org 1.71 Hart voor Internetvrijheid
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale malicious actors
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 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-cont...@to-surf-and-protect.net 22.73 > Foundation for Applied Privacy
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale malicious actors
Hi nusenu, this sounds quite useful and I would like to support it. I would be fine to do an email and physical address verifiation. Cheers Fabian Am 05.07.20 um 17:54 schrieb nusenu: > nick AT calyx dot com 0x2B791A2036D9D3AD.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Thanks for all the positive off-list feedback so far! >> a) require a verified email address for the exit or guard relay flag. >> (automated verification, many relays) > > Wouldn't that be a hurdle for a lot of relay operators? I can imagine > that many operators (of smaller relays) don't publish contact > information for privacy reasons. I believe you can have a valid ContactInfo and privacy. > Of course, in your proposal that > information would only be shared with the directory authorities That is not necessarily the case if the ContactInfo field is used without encryption, basically it is not specified yet. > but do > we have any numbers on how many relay operators are okay with this? I can only give you numbers based on the current tor network data (but that is not an answer to your question since it does not reveal anything about the operator's intention) ~71% of tor's guard capacity has a non-empty ContactInfo. About 700 guard relays have no ContactInfo set and are older than 1 month. ~89% of tor's exit capacity has a non-empty ContactInfo. Only about 60 exit relays have no ContactInfo set and are older than 1 month. >> 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]. >> > > However, 0.5% seems like an arbitrary number to me. Can you provide > some background information on how you got to this percentage? Is there > maybe some way to calculate a malicious relay operator's > deanonymisation success rate? The reasoning behind the specific threshold will be covered in more detail in the upcoming blog post. >> 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. > > Please don't assume that all big relay operators are happy with sharing > their physical address because most of them already do. Maybe we can > poll the big relay operators to find out if they are okay with this? (I > don't know if all of them are represented on this list) In fact, my initial email went to many operators (after the mailing list was not happy with so many recipients I did resend it to the list without the others in TO, so unfortunately you no longer see the full list of recipients), but yes, that is the point of this email - getting feedback from operators, especially from big ones. I a few replied already. > It is definitely an interesting idea, one that I have not thought of at > least. But I'm not sure if it would be effective at preventing what it > tries to prevent. Yes, that is basically the key question and since there appears to be a lot of money involved in running malicious relays, they certainly have enough money to buy some office services in some random place and get a physical address verified but one of the other factors of the proposal is also the additional time required for an attacker to go trough the process and that it can no longer be automated completely. kind regards, nusenu -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
On Sun, 5 Jul 2020 at 17:36, nusenu 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
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Pascal Terjan: > 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% Yes, they will try to circumvent thresholds by pretending to not be a group. The good thing is that this requires additional resources and time on the attacker side to hide the fact that they are adding many relays without triggering certain detections. kind regards, nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Hi nusenu Thank's you for your encouraging efforts to keep things safe. Am 05.07.2020 um 18:35 schrieb nusenu: 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 Is an issue real or not? Any answer to that question does not contradict a substantial method. Right, the proposed measure is not against sneek-in attackers but it buys time to detect and tackle sudden issues. Let's move forward. I hear you. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Hi nusenu, On Sun, 2020-07-05 at 18:35 +0200, nusenu wrote: > https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548 This was an interesting article, thanks for sharing. It's sad to read that you and the anonymous Tor core member weren't heard on the bad- relays list. Did you ever get a reply from a directory authority? I would assume that the dir auths are very keen to discuss this subject. > 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) Wouldn't that be a hurdle for a lot of relay operators? I can imagine that many operators (of smaller relays) don't publish contact information for privacy reasons. Of course, in your proposal that information would only be shared with the directory authorities, but do we have any numbers on how many relay operators are okay with this? You mention that the current defenses are inadequate for protection against slowly-added dispersed relays that are run by malicious actors. Wouldn't introducing this requirement prevent some relay operators with good intentions from serving exit or guard relays? Furthermore, do we have any information on how much more difficult it would become to perform a sybil attack if your proposal is implemented? Assuming that this is something that can be somewhat accurately measured. > 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. That seems reasonable. I currently co-run an exit relay that has just under 0.1% probability and would be okay with sharing my physical address with the directory authorities, especially if my probability would be higher. However, 0.5% seems like an arbitrary number to me. Can you provide some background information on how you got to this percentage? Is there maybe some way to calculate a malicious relay operator's deanonymisation success rate? > > 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. Please don't assume that all big relay operators are happy with sharing their physical address because most of them already do. Maybe we can poll the big relay operators to find out if they are okay with this? (I don't know if all of them are represented on this list) Edit: looks like niftybunny is already on this. > At the end of the upcoming blog post I'd like to give people some > idea as to how much support this proposal has. Great, I'm looking forward to this. It's a good thing to publicly discuss proposals like these. > 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. It is definitely an interesting idea, one that I have not thought of at least. But I'm not sure if it would be effective at preventing what it tries to prevent. Ultimately, the best solution for the sybil-attacks- are-easy problem is simple: we need more bandwidth provided by relays from operators with good intentions. Imre signature.asc Description: This is a digitally signed message part ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Thanks for the detailed reply, nusenu. Looks like you thought this through really well. It would be nice if Tor core people would chip in on this as well! @arma, @teor maybe? See my further comments inline. On Sun, 2020-07-05 at 22:50 +0200, nusenu wrote: > I believe you can have a valid ContactInfo and privacy. I do too, but I hope that prospective operators think so as well. > > Of course, in your proposal that information would only be shared > > with the directory authorities > > That is not necessarily the case if the ContactInfo field is used > without encryption, basically it is not specified yet. > > > but do we have any numbers on how many relay operators are okay > > with this? > > I can only give you numbers based on the current tor network data > (but that is not an answer to your question since it does not reveal > anything about the operator's intention) > > ~71% of tor's guard capacity has a non-empty ContactInfo. > About 700 guard relays have no ContactInfo set and are older than 1 > month. > > ~89% of tor's exit capacity has a non-empty ContactInfo. > Only about 60 exit relays have no ContactInfo set and are older than > 1 month. Those numbers look encouraging to me. It's good to see that most operators are doing things the right way, i.e. being reachable in case something happens to their relay. Still not 100% though. > The reasoning behind the specific threshold will be covered > in more detail in the upcoming blog post. Now you're making me really curious. > In fact, my initial email went to many operators (after the mailing > list was not happy with so many recipients > I did resend it to the list without the others in TO, so > unfortunately you no longer see the full list of recipients), > but yes, that is the point of this email - getting feedback from > operators, especially from big ones. > I a few replied already. That's great! Let's see what they think. > > It is definitely an interesting idea, one that I have not thought > > of at least. But I'm not sure if it would be effective at > > preventing what it tries to prevent. > > Yes, that is basically the key question and since there appears to be > a lot of money involved in running malicious relays, they certainly > have enough money to buy some office services in some random place > and get a physical address verified but one of the other factors of > the proposal is also the additional time required for an attacker to > go trough the process and that it can no longer be automated > completely. It would be very interesting to know who pays for that. If we figure that out, then maybe we can pursuade them to donate that money to the Tor Project instead. \s Imre signature.asc Description: This is a digitally signed message part ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
I have nothing against this proposal although im not sure it would be that much efficient. Especially, how does it make relay operations 'less sustainable' or 'more risky'? @Imre Jonk: why would you want - and why should you have - an higher probability? Sounds to me the ideal case is an infinite amount of independent exits with an almost-zero probability. C On Mon, Jul 6, 2020 at 12:28 AM Felix wrote: > Hi nusenu > > Thank's you for your encouraging efforts to keep things safe. > > Am 05.07.2020 um 18:35 schrieb nusenu: > > 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 > > Is an issue real or not? Any answer to that question does not contradict > a substantial method. Right, the proposed measure is not against > sneek-in attackers but it buys time to detect and tackle sudden issues. > Let's move forward. I hear you. > > -- > Cheers, Felix > ___ > 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
