- tor-relays - lists.torproject.org

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

Tor is not upgrading via apt from deb.torproject.org
by s7r 23 Mar '24

23 Mar '24

Hello all, I have recently found something interesting on my relays. On all relays and clients actually. As always I am using Debian and apt to get Tor from deb.torproject.org tor-nightly-main-bullseye main (for example). I also have the keyring installed, proper key and everything. Currently I am on: Tor version 0.4.9.0-alpha-dev. This build of Tor is covered by the GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html) Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1w, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc. Tor compiled with GCC version 10.2.1 Since October 2023. If I manually check out deb.torproject.org with my browser I see there is another package released in February 2024, except it notes as the same version 4.9.0-alpha-dev but it has a different timestamp. $ apt update reports no errors, looks like is working fine, but it doesn't notify there's a newer version and does not apply any updates to Tor. This happens only to Tor package from nightly, rest of packages from debian.org deb are updated as usual. So, anyone else experienced this? Do I need to configure apt in a different way than we used to do? I maintain this style of setup for Tor since Debian 7 :-), any changes needed? Thank you! -s7r

5 8

Problem with relay and ovh??
by Keifer Bly 07 Mar '24

07 Mar '24

Hi, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… Goes offline at sporadic times. Upon checking the tor log file, there does not appear to be anything written causing tor to crash: Feb 18 00:36:34.000 [notice] Tor 0.4.8.10 opening new log file. Feb 18 00:36:34.630 [notice] We compiled with OpenSSL 101010ef: OpenSSL 1.1.1n 15 Mar 2022 and we are running with OpenSSL 101010ef: 1.1.1n. These two versions should be binary compatible. Feb 18 00:36:34.634 [notice] Tor 0.4.8.10 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Feb 18 00:36:34.634 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Feb 18 00:36:34.636 [notice] Read configuration file "/etc/tor/torrc". Feb 18 00:36:34.637 [notice] Based on detected system memory, MaxMemInQueues is set to 1462 MB. You can override this by setting MaxMemInQueues by hand. Feb 18 00:36:34.640 [notice] Opening OR listener on 0.0.0.0:9001 Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on 0.0.0.0:9001 Feb 18 00:36:34.640 [notice] Opening OR listener on [::]:9001 Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on [::]:9001 Feb 18 00:36:34.640 [notice] Opening Directory listener on 0.0.0.0:9030 Feb 18 00:36:34.640 [notice] Opened Directory listener connection (ready) on 0.0.0.0:9030 Feb 18 00:36:35.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Feb 18 00:36:35.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. Feb 18 00:36:35.000 [notice] Your Tor server's identity key fingerprint is 'udeserveprivacy 79E3B585803DE805CCBC00C1EF36B1E74372861D' Feb 18 00:36:35.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'udeserveprivacy b7n+DkH5IsJHJexEqilhQ5tC0LRd9Td888RZpYkxEvc' Feb 18 00:36:35.000 [notice] Bootstrapped 0% (starting): Starting Feb 18 00:36:49.000 [notice] Starting with guard context "default" Feb 18 00:36:50.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. Feb 18 00:36:50.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Feb 18 00:36:50.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Unless the old file is being overwritten when tor restarts. But is there a known problem with OVH that causes this? Thanks. Oddly there is no definite time when this happens, sometimes the relay operates no problem for weeks on end and then it happens, other times it only makes it a day or two. --Keifer

3 4

Next Tor Relay Operator Meetup - March 2nd, 2024 @ 19.00 UTC
by gus 05 Mar '24

05 Mar '24

Hello Tor Relay operators, Please save the date! The next Tor Relay Operator Meetup will happen on Saturday, March 2nd at 2024 at 19.00 UTC. We're still working on the agenda for this meetup, however feel free to add your topics directly to the ticket or just reply to the mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/86 Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: March 2nd, 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. best, Gus -- The Tor Project Community Team Lead

1 3

Worse throughput with 0.4.8.x, on a slow CPU
by Roman Mamedov 04 Mar '24

04 Mar '24

Hello, Ater upgrading from Tor 0.4.7.13 to 0.4.8.9, I get a much worse bandwidth numbers. The CPU is Atom C2338 with two cores at 1.75 Ghz. Multiple Tor instances are running to take advantage of both cores. On the older version it gets about 80+80 Mbit total in+out. On the new one the average is at most 45+45 Mbit. There are frequent periods where the bandwidth drops to 5-10 Mbit for 3-5 seconds, while all Tor processes continue to use 100% of both CPUs, then gradually climbs back up. Does anyone notice anything similar? Here's how it looks for a few days on 0.4.8 then a roll-back: ------------------------+-------------+-------------+--------------- today 461.94 GiB | 470.84 GiB | 932.78 GiB | 153.98 Mbit/s ######################################## 12/12/23 462.81 GiB | 475.67 GiB | 938.48 GiB | 91.12 Mbit/s ####################### 12/11/23 434.72 GiB | 443.08 GiB | 877.80 GiB | 85.23 Mbit/s ###################### 12/10/23 446.13 GiB | 459.56 GiB | 905.70 GiB | 87.93 Mbit/s ####################### 12/09/23 464.79 GiB | 473.17 GiB | 937.96 GiB | 91.07 Mbit/s ####################### 12/08/23 454.67 GiB | 463.48 GiB | 918.16 GiB | 89.14 Mbit/s ####################### 12/07/23 463.82 GiB | 472.84 GiB | 936.65 GiB | 90.94 Mbit/s ####################### 12/06/23 670.01 GiB | 680.55 GiB | 1.32 TiB | 131.13 Mbit/s ################################## 12/05/23 808.50 GiB | 817.32 GiB | 1.59 TiB | 157.85 Mbit/s ######################################### 12/04/23 854.09 GiB | 866.43 GiB | 1.68 TiB | 167.05 Mbit/s ########################################### 12/03/23 782.20 GiB | 799.00 GiB | 1.54 TiB | 153.52 Mbit/s ######################################## 12/02/23 805.18 GiB | 817.91 GiB | 1.59 TiB | 157.59 Mbit/s ######################################### 12/01/23 733.80 GiB | 745.35 GiB | 1.44 TiB | 143.61 Mbit/s ##################################### 11/30/23 742.48 GiB | 756.56 GiB | 1.46 TiB | 145.54 Mbit/s ##################################### 11/29/23 657.90 GiB | 673.66 GiB | 1.30 TiB | 129.28 Mbit/s ################################# In general, are there any tweaks to reduce relay CPU usage on a slow processor? I did seemingly most of what is possible, ethtool, iptables, sysctl, etc. How long before the Rust-based Tor will be ready for use on relays? -- With respect, Roman

4 5

Re: [tor-relays] bridges for Lox
by Holonet 04 Mar '24

04 Mar '24

> On 27 Feb 2024, at 15:39, boldsuck <lists(a)for-privacy.net> wrote: > On Dienstag, 27. Februar 2024 14:52:00 CET Corl3ss via tor-relays wrote: >> On 26/02/2024 21:03, Toralf Förster via tor-relays wrote: >>> On 2/26/24 20:07, meskio wrote: >>>> At the moment we're >>>> looking for 10 new bridges for Lox. >>> 9 left >> >> And one more added, so 8 left. > +1 = 7 left Added one. 6 left.

4 3