March 2024 - tor-relays - lists.torproject.org

Attempting to create a relay with Orbot
by blueapple128 20 Jun '25

20 Jun '25

Hi, I am trying to use Orbot's "Enable your device to be a non-exit relay" option, but (after waiting enough hours) the relay's nickname fails to show up in Tor Metrics' Relay Search. How can I begin to debug this?

2 2

Recent Tor versions not reloading config on / ignoring HUP kill signal.
by George Hartley 10 Aug '24

10 Aug '24

Hi, I think this started with release 0.4.8.10, but both of my Tor relays no longer reload their config when doing for example: - systemctl reload tor@exit Here is the relevant part of the unit file: > [Unit]Description=Anonymizing overlay network for TCP > After=syslog.target network.target nss-lookup.target > > [Service] > Type=notify > NotifyAccess=all > ExecStartPre=/usr/bin/tor -f /etc/tor/torrc_%i --verify-config > ExecStart=/usr/bin/tor -f /etc/tor/torrc_%i > ExecReload=/bin/kill -HUP ${MAINPID} > KillSignal=SIGINT > TimeoutSec=75 > Restart=on-failure > WatchdogSec=1m > LimitNOFILE=32768 Checking with: - journalctl -u tor@exit Just tells me that systemd attempted and successfully executed the specified reload command, but the actual line from the Tor instance stating that the config has been reloaded is missing. Is anyone else experiencing this? Regards, George

2 2

Request for Feedback on Relay Node Update Management
by Alessandro Greco 19 Apr '24

19 Apr '24

Dear Tor-Relays Mailing List Members, I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours. This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities. As such, I'd like to pose some questions to the community to gather feedback and assess best practices: 1. In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability? 2. Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security? 3. Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes? Thank you in advance for your time and cooperation. Best regards, Aleff. [1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524415E52E… [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/updates/ --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

6 11

Node 6E02FDEA15122A492A799A58C4C11D02637B145A is marked as down, but logs display no issues
by 0N ODV 08 Apr '24

08 Apr '24

Hi all, our node sacco.osservatorionessuno.org[1] has been marked down for more than a couple of days. It is at the latest version from Tor's Debian repository and I tried to restart both the service and the server. The process is running, and the 9001 and 9030 ports are open and succesfully reachable from the outside. The notice log I temporarily enabled to look for the issue apparently does not show any warning signs. Here is an anonymized output of the log: [notice] Tor 0.4.8.10 opening new log file. [notice] We compiled with OpenSSL XXX and we are running with OpenSSL XXX. These two versions should be binary compatible. [notice] Tor 0.4.8.10 running on Linux with Libevent XXX, OpenSSL XXX, Zlib XXX, Liblzma XXX, Libzstd XXX and Glibc XXX as libc. [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ [notice] Read configuration file "/etc/tor/torrc". [notice] Based on detected system memory, MaxMemInQueues is set to 720 MB. You can override this by setting MaxMemInQueues by hand. [notice] Opening Socks listener on 127.0.0.1:9050 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050 [notice] Opening OR listener on XXX:9001 [notice] Opened OR listener connection (ready) on XXX:9001 [notice] Opening OR listener on [XXX]:9001 [notice] Opened OR listener connection (ready) on [XXX]:9001 [notice] Opening Directory listener on XXX:9030 [notice] Opened Directory listener connection (ready) on XXX:9030 [notice] Opening Directory listener on [XXX]:9030 [notice] Opened Directory listener connection (ready) on [XXX]:9030 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. [notice] Your Tor server's identity key fingerprint is 'sacco XXX' [notice] Your Tor server's identity key ed25519 fingerprint is 'sacco XXX' [notice] Bootstrapped 0% (starting): Starting [notice] Starting with guard context "default" [notice] Bootstrapped 5% (conn): Connecting to a relay [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address. [notice] Bootstrapped 10% (conn_done): Connected to a relay [notice] Bootstrapped 14% (handshake): Handshaking with a relay [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit [notice] External address seen and suggested by a directory authority: XXX [notice] Bootstrapped 100% (done): Done [notice] Now checking whether IPv4 ORPort XXX:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) [notice] Now checking whether IPv6 ORPort [XXX]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) [notice] Self-testing indicates your ORPort XXX:9001 is reachable from the outside. Excellent. [notice] Performing bandwidth self-test...done. [notice] Self-testing indicates your ORPort [XXX]:9001 is reachable from the outside. Excellent. Publishing server descriptor. [notice] Heartbeat: It seems like we are not in the cached consensus. [notice] Heartbeat: Tor's uptime is XX hours, with XX circuits open. I've sent XX and received XX. I've received XXX connections on IPv4 and XXX on IPv6. I've made XXX connections with IPv4 and XXX with IPv6. [notice] While bootstrapping, fetched this many bytes: XXX (microdescriptor fetch) [notice] While not bootstrapping, fetched this many bytes: XXX (server descriptor fetch); XXX (server descriptor upload); XXX (consensus network-status fetch); XXX (microdescriptor fetch) [notice] Circuit handshake stats since last time: X/X TAP, X/X NTor. [notice] Since startup we initiated XXX and received XXX v1 connections; initiated 0 and received 0 v2 connections; initiated XXX and received XXX v3 connections; initiated XXX and received XXX v4 connections; initiated XXX and received XXX v5 connections. [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. [notice] Your network connection speed appears to have changed. Resetting timeout to XXXms after XXX timeouts and XXX buildtimes. We would appreciate any hint on how to proceed to debug the issue in order to keep the server useful. Thank you Giuio [1] - https://metrics.torproject.org/rs.html#details/6E02FDEA15122A492A799A58C4C1…

3 3

User advisory to check for xz-utils backdoor
by pasture_clubbed242＠simplelogin.com 02 Apr '24

02 Apr '24

Greetings, I do not normally use mailing lists such as this one to inform subscribers of security notices, but this issue is extreme enough where it may benefit the anonymity of Tor users if relay operators are aware of it sooner. The near-universally used 'xz' compression library has been found to contain a backdoor in certain code branches. This backdoor has made it into some systems such as Debian Sid. Details regarding this backdoor are available here. https://www.openwall.com/lists/oss-security/2024/03/29/4 It is suspected that if your OpenSSH server links to the xz library, which Debian appears to do so, then this backdoor is remotely exploitable. If your OpenSSH server does not link to this library, then your system still contains many processes that run xz actions as the root user, some input of which may be less than trusted. For those needing a patch, I recommend you research your distribution's security advisory page for further information. References: Debian Sid Advisory: https://security-tracker.debian.org/tracker/CVE-2024-3094

2 1

Backdoor in upstream xz/liblzma leading to ssh server compromise
by hello＠relaymagic.org 02 Apr '24

02 Apr '24

Just wanted to bring this to everyone’s attention if you hadn’t seen it already. Developer discovered a backdoor in xz-utils https://www.openwall.com/lists/oss-security/2024/03/29/4 -- Sent from Canary (https://canarymail.io)

2 1

Tor relay operator research
by Ana Custura 29 Mar '24

29 Mar '24

Dear operators, We're conducting a study to understand relay operator motivations and needs, funded by OTF. We've already interviewed several of you and got feedback relating to community matters. Based on that feedback, we've put together a comprehensive survey: English: https://survey.torproject.org/index.php/751125?lang=en Spanish: https://survey.torproject.org/index.php/751125?lang=es If you have about 30 minutes to spare and fill this in, it would be much appreciated! Your responses are valuable and will be used by the Tor project to understand the needs of the community, and how you feel about some controversial Tor-related issues. The survey is anonymous. Cheers Ana PS: to find out more about the project, see https://www.opentech.fund/projects-we-support/supported-projects/the-tor-pr…

1 0

Announcement: Tor-Weather 2.0 Release
by Sarthik Gupta 27 Mar '24

27 Mar '24

Dear Tor-Relay Community, I hope this email finds you well. I am excited to announce the release of Tor-Weather 2.0, a significant rewrite of our Tor-Weather service. This release was primarily focused on refactoring the codebase, resulting in extensive changes. This initiative not only enhances the existing codebase but also accelerates the development of new features and addresses numerous bugs in the current service. Some of the key highlights of Tor-Weather 2.0 include: 1. Support for bridges: We have added support for tracking bridges. Creating subscriptions for bridges works the same way as creating those for relays. 2. Improved email templates: Emails have been completely revamped & will now offer both html & txt based mime-types. No more incorrectly spaced emails. 3. Added additional details in emails: We've added additional details to the emails. This includes, link to the relay's metric page, additional context for the subscription, etc. 4. Improved reliability & bug-fixes: The new deployment process should greatly improve the availability & reliability of the service. This also includes bunch of bug-fixes across the application. We believe that these updates will greatly benefit the Tor-Relay community and contribute to a more streamlined and efficient relay management experience. To start using Tor-Weather 2.0, simply visit [Tor-Weather](https://weather.torproject.org/login) and log in with your existing credentials. If you encounter any issues, please file a ticket in our [bug tracker](https://gitlab.torproject.org/tpo/network-health/tor-weather/-/iss…. Thank you for your continued support and participation in the Tor-Relay community. We look forward to hearing your thoughts on Tor-Weather 2.0 and continuing to improve our services to better serve your needs. Best regards, Sarthik Gupta & Network-Health Team

1 0

Re: [tor-relays] Request for Feedback on Relay Node Update Management
by denny.obreham＠a-n-o-n-y-m-e.net 26 Mar '24

26 Mar '24

Relays do restart for different reasons. For example, two of my relays (the upgrade process is automated on both) were restarted on March 23rd, practically at the same time. Different OS versions on different machines from different ISP for both relays. One was restarted because some libraries needed to be upgraded on the system: ``` The following packages will be upgraded: libbsd0 libc-bin libc6 libxslt1.1 locales 5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [...] Restarting services... [...] tor(a)default.service [...] ``` The server even needed to be rebooted afterward. The other one had a very different reason, as you can see from the syslog: ``` Mar 23 03:07:43 leslie kernel: [849147.801728] Out of memory: Killed process 930 (tor) total-vm:850180kB, anon-rss:620800kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:1652kB oom_score_adj:0 Mar 23 03:07:43 leslie systemd[1]: tor(a)Leslie.service: A process of this unit has been killed by the OOM killer. Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Main process exited, code=killed, status=9/KILL Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Failed with result 'oom-kill'. Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Consumed 2d 5h 54min 39.122s CPU time. Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Scheduled restart job, restart counter is at 1. Mar 23 03:07:44 leslie systemd[1]: Stopped Anonymizing overlay network for TCP (instance Leslie). Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Consumed 2d 5h 54min 39.122s CPU time. Mar 23 03:07:44 leslie systemd[1]: Starting Anonymizing overlay network for TCP (instance Leslie)... ``` That was the last time both relays were restarted (~ 3 days ago) Denny On 03/26/2024 04:54 AM Alessandro Greco via tor-relays wrote .. Dear Tor-Relays Mailing List Members, I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours. This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities. As such, I'd like to pose some questions to the community to gather feedback and assess best practices: 1. In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability? 2. Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security? 3. Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes? Thank you in advance for your time and cooperation. Best regards, Aleff. [1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524 415E52E3BE81E63056B [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/upd ates/ --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

1 0

GeoIPFile option warning
by krishna e bera 25 Mar '24

25 Mar '24

I am seeing these warnings in Tor's notices.log: Mar 24 09:42:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Mar 24 09:42:21.000 [notice] Configured to measure entry node statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. However the option is set in torrc and i verified the files are at those locations and readable by all: GeoIPFile /usr/local/share/tor/geoip GeoIPv6File /usr/local/share/tor/geoip6 Any hints how i could check whether the warnings are spurious or dump what the running config actually is? I know it is reading the torrc because introducing an error in the file stops it from loading.

2 1