tor-relays August 2020

tor-relays@lists.torproject.org

46 participants
32 discussions

Call for Testing - New Feature: Relay IPv6 Address Discovery
by David Goulet 28 Nov '20

28 Nov '20

Greetings everyone! We've very recently merged upstream (tor.git) full IPv6 supports which implies many many things. We are still finalizing the work but most of it is in at the moment. This is a call for help if anyone would like to test either git master[1] or nightly builds[2] (only Debian) to test for us a specific feature. The feature we would love for some of you to test is the IPv6 address discovery. In short, with this new feature, specifying an ORPort without an address will automatically bind tor to [::]:<port> and attempt to find the IPv6 address by looking at (in this order): 1. "Address" from torrc 2. "ORPort address:port" from torrc 3. Interface address. First public IPv6 is used. 4. Local hostname, DNS AAAA query. If all fails, the relay will simply never publish an IPv6 in the descriptor but it will work properly with the IPv4 (still mandatory). The other new thing is that now tor supports *two* "Address" statement which can be a hostname or IPv4 or IPv6 now. Thus this is now valid: Address 1.2.3.4 Address [4242::4242] ORPort 9001 Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4 for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the address to use to reach your relay's ORPort. Now, if you happen to have this configuration which I believe might be common at the moment: ORPort 9001 ORPort [4242::4242]:9001 The second ORPort which specifies an IPv6 address will supersede the "ORPort 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and [4242::4242]:9001. You should get a notice log about this. Thus the recommended configuration to avoid that log notice would be to bind to specific addresses per family: ORPort <IPv4>:9001 ORPort <IPv6>:9001 And of course, if you want your relay to _not_ listen on IPv6: ORPort 9001 IPv4Only In your notice log, you will see which address is used to bind on the ORPort and then you will see the reachability test succeed or not on the address that tor either used from the configuration or auto discovered that is the address you are supposedly reachable from. Man page has NOT been updated yet, it will arrive once we stabilize the IPv6 feature and everything around it. Please, do report (on this thread) _anything_ even slightly annoying about this like logging or lack of logging and so on. This is a complex feature and errors can be made thus any testing you can offer is extremely appreciated. Thanks!! David [1] https://gitweb.torproject.org/tor.git/ [2] https://2019.www.torproject.org/docs/debian.html.en -- EeJVrrC/dHQXEXYB1ShOOZ4QuQ8PMnRY2XGq4BYsFq4=

8 12

Heartbeat: It seems like we are not in the cached consensus.
by Fran 27 Sep '20

27 Sep '20

Hello, I'm taking care of a server of a friend who's on holiday. The server is up and running but not part of the consensus. As beeing instructed I updated to the lastest OpenBSD snapshot when I saw that a new tor release is available (Tor 0.4.3.5 on OpenBSD). Excerpts from the log: Jul 13 20:04:02.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jul 13 20:05:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jul 13 20:05:35.000 [notice] Performing bandwidth self-test...done. Jul 14 02:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 02:04:01.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 2.04 MB and received 6.25 MB. Jul 14 02:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 33% Jul 14 02:04:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor. Jul 14 02:04:01.000 [notice] Since startup we initiated 0 and received 157 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 5 v4 connections; initiated 48 and received 124 v5 connections. Jul 14 02:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 06:04:02.000 [notice] Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 4 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections. Jul 14 08:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 08:04:01.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 1 circuits open. I've sent 3.46 MB and received 11.22 MB. Jul 14 08:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 47% Jul 14 08:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 1/1 NTor. Jul 14 08:04:01.000 [notice] Since startup we initiated 0 and received 340 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 10 v4 connections; initiated 57 and received 246 v5 connections. Jul 14 08:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 14:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 14:04:01.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 1 circuits open. I've sent 4.89 MB and received 15.33 MB. Jul 14 14:04:01.000 [notice] Average packaged cell fullness: 26.760%. TLS write overhead: 51% Jul 14 14:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 6/6 NTor. Jul 14 14:04:01.000 [notice] Since startup we initiated 0 and received 493 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 18 v4 connections; initiated 64 and received 370 v5 connections. Jul 14 14:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Atlas show the server as down: https://metrics.torproject.org/rs.html#details/AC601DBDB7FBD53454045EDC08DA… Accessing the status page on port 80 works. No FW on the machine. Any ideas? Thanks and regards Fran

4 7

Become a Fallback Directory Mirror (deadline: July 23)
by gus 17 Sep '20

17 Sep '20

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. Important: you have until July 23 2020 to reply to this message to get in the fallback directory mirror list. If your relay is on the current fallback list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, Gus [1] https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDire… [2] https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc [3] https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_… -- The Tor Project Community Team Lead http://expyuzz4wqqyqhjn.onion/

26 30

How many threads needed for unbound at a fast relay?
by Toralf Förster 05 Sep '20

05 Sep '20

I do wonder about a reasonable number. -- Toralf

3 3

anyone else with this issue?
by niftybunny 30 Aug '20

30 Aug '20

Daily DDOS love the last 14 days … https://imgur.com/a/rfu0OUA <https://imgur.com/fCsIv6V> even for my standards, thats a shit-ton of sockets … Tor DDOS protection is configured but I get more connections than I can drop … nifty

7 9

ubuntu focal and Tor
by potlatch 28 Aug '20

28 Aug '20

Question: What's with the failure when installing Tor of the "no valid keys" for focal? I've had to back up to ubuntu 18 several times. --potlatch-- Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Hello CypherpunkLabs Tor relays
by nusenu 25 Aug '20

25 Aug '20

Hello CypherpunkLabs, I noticed your set of new relays and wanted to say hi, welcome you to the Tor relay community and give you a few recommendations and pointers especially since you are aiming to run 100 tor relays. The Tor relay guide has a lot of useful information, so you probably want to start there: https://torproject.org/relay-guide Since all your current relays appear to be OVH based I'd like to point out the following quote from the guide: > Try to avoid the following hosters: > > OVH SAS (AS16276) > Online S.a.s. (AS12876) > Hetzner Online GmbH (AS24940) > DigitalOcean, LLC (AS14061) https://community.torproject.org/relay/technical-considerations/ The reasoning behind this, is that those hosters are already hosting many tor relays, and the network dislikes centralization. OVH is the biggest commercially available tor hoster in terms of exit capacity today already. Depending on your per-relay size you might end up running a big fraction of the network and especially big exit operators are encourage to take care of their DNS resolution. Specific guidelines can be found here: https://community.torproject.org/relay/setup/exit/ IPv6 connectivity is also encouraged (which currently none of your relays appear to have). Especially for big operators it is recommended to managed their relays using configuration management (puppet, salt, ansible, ...) and update them regularly. An ansible role for Tor relay operator (I maintain) can be found at: https://github.com/nusenu/ansible-relayor The ContactInfo Information Sharing Specification is a spec about a machine readable ContactInfo string: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification Your site suggests that you (will) run bridges and exits. Combining these two types of nodes under a single operator is generally a bad idea since tor's MyFamily configuration is not supported for bridges, so users might end up using your bridges _and_ your tor exits - which puts them at risk should someone compromise you, please consider running non-bridges only. For strong protections for your long term relay keys you can use tor's OfflineMasterKey feature, especially relevant if your run a big fraction of the network: https://2019.www.torproject.org/docs/tor-manual.html.en#OfflineMasterKey kind regards, nusenu PS: don't forget about your MyFamily setting if you do not choose a solution that manages that for you automatically. -- https://mastodon.social/@nusenu

2 1

IPv6 Support or Uptime?
by Josh Lawson 24 Aug '20

24 Aug '20

I have IPv6 with my ISP, but there seems to be a bug in the firmware of my networking equipment that causes IPv6 to stop working periodically and I have to take my network down and bring it back up. If I do not do this, my relay stops functioning as I have torrc configured to use IPv6 and IPv4. So, my question is whether or not having a higher uptime is more important or having IPv6 support? My relay never goes down when on IPv4 only. I apparently cannot have both until the firmware bug is fixed. I appreciate it!

4 4

Tor bandwidth scanner "longclaw" slow to the US West Coast
by Neel Chauhan 23 Aug '20

23 Aug '20

Hi, I believe the Tor bandwidth scanner nicknamed "longclaw" is measuring relays in the US West Coast worse than other bandwidth scanners in North America. This happens on multiple ISPs, both ones I have and ones I don't. This includes two Tor exit instances on a dedicated server hosted in Los Angeles on Psychz Networks (AS40676): https://metrics.torproject.org/rs.html#details/156AAC3FAD1ACC8906316519DCB4… https://metrics.torproject.org/rs.html#details/A69CEB30328B1E85C6B167FECAF2… And two Tor non-exit instances on a home server in Seattle on Wave Broadband (AS11404), using a symmetrical Gigabit link: https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… The consensus weight values from longclaw are much lower than other North American bandwidth scanners, according to https://consensus-health.torproject.org/. This also affects other relays/ISPs on the West Coast US/Canada, such as Emerald Onion, AT&T U-verse, Sonic.net, and QuadraNet. The same ISPs/hosts in the East Coast aren't affected. This discrepancy in the measurement disproportionately favors European and East Coast US/Canada relays at the expense of West Coast relays, centralizing the Tor network even further than it already was. This wasn't an issue in the past, even as early as a few months ago. It only started appearing around June. Is anyone else hosting West Coast relays having this issue? Is "longclaw" actually measuring bandwidth from Europe? If so, WHY? I got in contact with "longclaw"'s admin and he wasn't too helpful. Best, Neel Chauhan === https://www.neelc.org/

4 4

Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)
by nusenu 23 Aug '20

23 Aug '20

Hi, here is my motivation for working on automated verification of operatorurls in ContactInfo: https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in… -- https://mastodon.social/@nusenu

9 16

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays August 2020