Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Hi, great to see that the Tor network can lose ~20% capacity without having impact on the performance of the complete network. So can we get rid of the non dual stack relays now too? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Please help us find a working alternative to using MaxMind's GeoLite2 databases
Hi Karsten I'm the operator of bauruine51 (185.204.1.239). Finland is the correct location and not Russia. Other relays with the same hoster which are also wrong: - SingularET - AutoNoMe - whatevr8 - BlackHall The nodes that are FI in MaxMind and DE in your alternative are mostly (all?) Hetzner Finland servers. e.g. Ranlvor and HORUS1. Best regards, Stefan On 07.07.20 11:19, Karsten Loesing wrote: On 2020-02-12 16:05, Karsten Loesing wrote: Hi relay operators, as you might have heard, MaxMind has changed access and use of their GeoLite2 databases: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ This affects Onionoo and tor, and I'm trying to find a working alternative on the following ticket: https://trac.torproject.org/projects/tor/ticket/32978 Today I think I found a possible alternative by using data from another provider. But before I name it here, I'd first want to find out how accurate it is. I tried resolving relay IP addresses of relays that have been running in the past week and compared that to our existing lookups using MaxMind's October database. The result is that 7669 relays (93%) had the same country code and ASN. I put the remaining 7% on the following wiki page: https://trac.torproject.org/projects/tor/wiki/doc/MetricsGeoipComparison I'd like to hear from you which data source is right and which is wrong (or if both are wrong). If you'd like to help, please leave comments on the ticket or in the "Comment" column on that wiki page by February 19, 2020. Thanks for helping! Hello again, I'm bumping this thread, because there's (finally) news on finding an alternative to MaxMind: https://gitlab.torproject.org/tpo/metrics/trac/-/issues/32978 (Yes, you'll have to scroll down quite a bit to find the news, it's a long ticket.) Can relay operators please take a look at that ticket and see if they find their relay in the table with different country results? It would be neat to identify patterns there and possibly improve the accuracy of the new database. Thanks for your help! All the best, Karsten ___ 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
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
On 7/7/20 7:13 PM, NOC wrote: > > great to see that the Tor network can lose ~20% capacity What let you think that this is correct ? -- Toralf 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
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 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@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
Re: [tor-relays] Please help us find a working alternative to using MaxMind's GeoLite2 databases
On Tue, 7 Jul 2020 at 10:20, Karsten Loesing wrote: > > On 2020-02-12 16:05, Karsten Loesing wrote: > > Hi relay operators, > > > > as you might have heard, MaxMind has changed access and use of their > > GeoLite2 databases: > > > > https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ > > > > This affects Onionoo and tor, and I'm trying to find a working > > alternative on the following ticket: > > > > https://trac.torproject.org/projects/tor/ticket/32978 > > > > Today I think I found a possible alternative by using data from another > > provider. But before I name it here, I'd first want to find out how > > accurate it is. > > > > I tried resolving relay IP addresses of relays that have been running in > > the past week and compared that to our existing lookups using MaxMind's > > October database. > > > > The result is that 7669 relays (93%) had the same country code and ASN. > > > > I put the remaining 7% on the following wiki page: > > > > https://trac.torproject.org/projects/tor/wiki/doc/MetricsGeoipComparison > > > > I'd like to hear from you which data source is right and which is wrong > > (or if both are wrong). > > > > If you'd like to help, please leave comments on the ticket or in the > > "Comment" column on that wiki page by February 19, 2020. > > > > Thanks for helping! > > Hello again, > > I'm bumping this thread, because there's (finally) news on finding an > alternative to MaxMind: > > https://gitlab.torproject.org/tpo/metrics/trac/-/issues/32978 > > (Yes, you'll have to scroll down quite a bit to find the news, it's a > long ticket.) > > Can relay operators please take a look at that ticket and see if they > find their relay in the table with different country results? > > It would be neat to identify patterns there and possibly improve the > accuracy of the new database. > > Thanks for your help! I run 3 relays with Scaleway, one in Paris and 2 in Amsterdam, the new alternative places them all in France. whois correctly describes the range as being in Amsterdam: % Information related to '51.15.0.0/17AS12876' route: 51.15.0.0/17 descr: SCALEWAY descr: Amsterdam, Netherlands origin: AS12876 mnt-by: MNT-TISCALIFR created:2019-10-03T15:11:06Z last-modified: 2019-10-03T15:11:06Z source: RIPE % This query was served by the RIPE Database Query Service version 1.97.2 (WAGYU) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Please help us find a working alternative to using MaxMind's GeoLite2 databases
On 2020-02-12 16:05, Karsten Loesing wrote: > Hi relay operators, > > as you might have heard, MaxMind has changed access and use of their > GeoLite2 databases: > > https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ > > This affects Onionoo and tor, and I'm trying to find a working > alternative on the following ticket: > > https://trac.torproject.org/projects/tor/ticket/32978 > > Today I think I found a possible alternative by using data from another > provider. But before I name it here, I'd first want to find out how > accurate it is. > > I tried resolving relay IP addresses of relays that have been running in > the past week and compared that to our existing lookups using MaxMind's > October database. > > The result is that 7669 relays (93%) had the same country code and ASN. > > I put the remaining 7% on the following wiki page: > > https://trac.torproject.org/projects/tor/wiki/doc/MetricsGeoipComparison > > I'd like to hear from you which data source is right and which is wrong > (or if both are wrong). > > If you'd like to help, please leave comments on the ticket or in the > "Comment" column on that wiki page by February 19, 2020. > > Thanks for helping! Hello again, I'm bumping this thread, because there's (finally) news on finding an alternative to MaxMind: https://gitlab.torproject.org/tpo/metrics/trac/-/issues/32978 (Yes, you'll have to scroll down quite a bit to find the news, it's a long ticket.) Can relay operators please take a look at that ticket and see if they find their relay in the table with different country results? It would be neat to identify patterns there and possibly improve the accuracy of the new database. Thanks for your help! All the best, Karsten 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
