[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



While I fully support the direction here I do wonder if there’s not also other information that could be used. Eg in bitcoin-land we have persistent issues with anti-privacy services operating large numbers of relays all one three  ASNs. In the future, we’ll likely be shipping a compressed netblock -> primary ASN (where we map stub ASNs that always transit one upstream to their upstream) table with the software to limit connections to the same networks. Last I heard, Tor’s sybil attackers did something similar, so at least forcing them to establish business relationships with many hosting providers by limiting percentage of relays in a given ASN may be somewhat limiting. If nothing else, it also captures another useful trait that you don’t want to just bounce your traffic across five hosts in different OVH datacenters from a traffic correlation perspective.

Matt

>> On Jul 5, 2020, at 13:51, nusenu <nusenu-lists@xxxxxxxxxx> wrote:
> 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
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays