tor-relays

tor-relays@lists.torproject.org

42 participants
4821 discussions

Please help us find a working alternative to using MaxMind's GeoLite2 databases
by Karsten Loesing 14 Jul '20

14 Jul '20

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-us… 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! All the best, Karsten

12 14

>23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
by nusenu 13 Jul '20

13 Jul '20

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-t… 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(a)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(a)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(a)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(a)privateinternetaccess.com 0.52 14 out of these 18 operators have their address already publicly listed because they are registered organizations or similar.

15 27

My Tor relay appears offline every 3 hours
by marsbanks 13 Jul '20

13 Jul '20

Since about 2 weeks ago, [my (non-exit) relay](https://metrics.torproject.org/rs.html#details/94626BD21119568EB301D… appears offline every 3 hours or so even though it's not actually offline. This lasts for about an hour each time, during which my relay also loses all its flags. However, it's reachable and pingable, and I still get some Tor traffic, though it's very reduced. I don't see any errors via Nyx or looking at my Tor logs. But after about an hour, everything seems to go back to normal: it comes back online, with the Fast, Running, V2Dir, and Valid flags. Does anyone have any clue what could be going on? I've been pulling my hair out trying to troubleshoot this, with no luck. And it's preventing my relay from getting the Stable flag, let alone finally becoming a Guard. Thanks in advance! Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

My relay appear down when it's actually up
by trinity Pointard 11 Jul '20

11 Jul '20

Hi, Since a few days, my relay A8503903F97FF27F5D1C3CA38817329F581925E6 appear down according to metrics.torproject.org, and is not getting the Running flag from 6 out of 9 authorities according to consensus-health.torproject.org. This happened when my ISP got an issue and my network falled back to a cellular network. Tor can't run as a relay on that network as my server isn't publicly reachable over it, but it's been 2 days since the problem was resolved, I've restarted Tor daemon half a dozen time (last restart does appear on metrics.torproject.org), and I'm still not getting the Running flag. Any idea of what I can do to put it back in working condition? I hope someone will have an idea, and I wish you all a nice day.

2 1

Re: [tor-relays] Become a Fallback Directory Mirror
by Bakullama 11 Jul '20

11 Jul '20

90B64F9E18B59AF322EBD28B8F8CD65C53E10CE1 ~ Bakullama ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 10 July 2020 13:00, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: Become a Fallback Directory Mirror (deadline: July 23) > (William Denton) > > > Message: 1 > Date: Thu, 9 Jul 2020 18:15:05 -0400 (EDT) > From: William Denton wtd(a)pobox.com > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Become a Fallback Directory Mirror > (deadline: July 23) > Message-ID: alpine.DEB.2.02.2007091814020.311(a)shell.miskatonic.org > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > C14CE6C2145688B640EB6457F39C1C6E1DC684D4 > > Bill > > > On 08/07/20 18:36, gus wrote: > > > > > Dear Relay Operators, > > > Do you want your relay to be a Tor fallback directory mirror? > > > Will it have the same address and port for the next 2 years? > > > Just reply to this email with your relay's fingerprint. > > -- > > William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ > https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ > Caveat lector. --- STAPLR: https://staplr.org/ > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Subject: Digest Footer > > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > -------------------------------------------------------------------------------------------------------------------------- > > End of tor-relays Digest, Vol 114, Issue 15

2 1

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
by entensaison＠use.startmail.com 10 Jul '20

10 Jul '20

Hi, On Sunday, July 5, 2020 at 8:45 PM, Imre Jonk <imre(a)imrejonk.nl> wrote: > Hi nusenu, > > On Sun, 2020-07-05 at 18:35 +0200, nusenu wrote: > [...] >> 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. This is a great point. Independent of the measures that will be chosen, they should impact the traffic a relay gets. Most relay operators want their relays to be useful and are willing to do put a lot of work into increasing their traffic. And they should be "rewarded" with flags so that it is obvious to relay operators that they have an interest in actually fulfilling the new requirements. > [...] >

1 0

Hardware specs for a high-bandwidth Tor exit?
by Christian Pietsch 09 Jul '20

09 Jul '20

Dear Tor friends, the NGO I am volunteering for (Digitalcourage e.V.) has been running modest Tor exits for many years. Now we finally have the opportunity to run a high-bandwidth exit relay because we found a data center with a nice internet connection (20 Gbit/s) we may use. My question is: What kind of hardware should we buy to utilize this bandwith? I am told that we need an SFP+ networking card to connect to the fibre optics cable, but what CPU and mainboard would you recommend nowadays? It should fit into a 1 height unit 19" enclosure. If you prefer to tell me in person: I will attend the Tor meetup in Brussels on Friday <https://blog.torproject.org/events/tor-meetup-brussels> and the subsequent Freedom Not Fear event <https://www.freedomnotfear.org/>. Cheers, Christian -- Christian Pietsch | volunteering for Digitalcourage e.V., Germany Digitalcourage e.V.: https://digitalcourage.de/ BigBrotherAwards Germany: https://bigbrotherawards.de/ Betting living without Google: https://pad.foebud.org/google-alternatives

3 3

Work with ISPs
by Charly Ghislain 08 Jul '20

08 Jul '20

Hi list, With the recent warning by nusenu about the malicious relays and the proposal to work around the issue , ive been wondering: Did anyone ever try to convince some isp to put a low-cap tor relay on the router of their 'unlimited bandwidth' clients? Or has there been any discussion on that matter already? I understand most would be strongly reticent, but I think some may find a commercial/marketing value in this. Thanks, Charly

2 1

Authority Nodes
by Vitor Milagres 06 Jul '20

06 Jul '20

Hi, I see the Authority Nodes are located only in North America and Europe. I would like to contribute to the TOR network as much as possible. I am currently running a node and I would like to make it an Authority Node as well. I am from Brazil and I believe it would possibly be a good idea to have a new Authority Node in South America. What are the requirements? What should I do to become one of them? FYI, the node I am running is 79DFB0E1D79D1306AF03A4B094C55A576989ABD1 Thanks, Vitor Milagres

8 9

Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale malicious actors
by niftybunny 05 Jul '20

05 Jul '20

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(a)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-t… > > 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(a)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(a)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(a)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(a)privateinternetaccess.com 0.52 > > 14 out of these 18 operators have their address already publicly listed because they are registered organizations or similar. > > >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays