- tor-relays - lists.torproject.org

We need to talk about the latest DDoS affecting the Tor network
by koizoi 25 May '24

25 May '24

For several weeks now, users have been complaining (see https://www.reddit.com/r/TOR/comments/1cnmsdz/tor_extremely_slow_lately/, https://forum.torproject.org/t/is-there-currently-a-major-ddos-affecting-th…, etc) about degraded performance (slow speeds, timeouts) when using Tor, both to access v3 onion sites and clearnet websites. In my personal experience, most v3 onion services are responding so slowly that they're completely unusable. it turns out that's it not just people's imaginations, looking at charts on metrics.torproject.org, it can be seen that the time to complete a 5MiB request over Tor has increased substantially (https://ibb.co/tp1CHdh) All of this is very reminiscent of the large scale DDoS that affected Tor relay nodes in 2022-2023. Tor relay operators have reported "attacks" on their relays, but there haven't been many details about what kind of attacks are taking place, other than some people saying that they have been TCP SYN flooded. But (to me, anyway) SYN flooding doesn't really make a lot of sense as there are so many Tor relay nodes that would need to be attacked, (and misconfigured to allow a SYN flood attack to work), and even if it were a SYN flood, that would cause different behavior than what users have been seeing (preventing connections to the Tor network rather than slowing them down). I understand that DDoS attacks on the Tor network might be kind of a touchy subject, but it would be good if we could get some information from the project leadership as to what's going on, what is being done about it, and what Tor relay operators can do to help prevent attacks like these from happening. Thanks Sent with [Proton Mail](https://proton.me/) secure email.

2 1

Next Tor relay operators meetup - May 11, 2024 at 19 UTC
by gus 14 May '24

14 May '24

Hi, Please save the date: the next Tor Relay Operator will happen Saturday, May 11 at 19UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to this ticket or just reply to the mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/92 Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: May 11, 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. I'll send soon the last meetup notes to the list. Gus -- The Tor Project Community Team Lead

2 3

disable conflux on exit relay?
by applied-privacy.net 14 May '24

14 May '24

Hello, conflux appears to be the primary source of bugs and crashes for us in the past few months and there have been numerous issues related to it on gitlab. from the tor manual page: ConfluxEnabled 0|1|auto If this option is set to 1, general purpose traffic will use Conflux which is traffic splitting among multiple legs (circuits). Onion services are not supported at the moment. Default value is set to "auto" meaning the consensus is used to decide unless set. (Default: auto) will ConfluxEnabled 0 disable it for tor acting as a client only or for relays as well? thanks! applied-privacy.net

4 7

Updating tor issue
by Keifer Bly 13 May '24

13 May '24

https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… Hi, so for my relay at the address above, when trying to update tor, suddenly getting the "updating from such a respiratory can't be done securly" message. Odd as this just suddenly started happening. Here is my sources file. What is the correct format for adding tor as a trusted source? Thanks. deb-src http://deb.debian.org/debian buster main ## Major bug fix updates produced after the final release of the ## distribution. deb http://security.debian.org/ buster/updates main deb-src http://security.debian.org/ buster/updates main ## Uncomment the following two lines to add software from the 'backports' ## repository. ## ## N.B. software from this repository may not have been tested as ## extensively as that contained in the main release, although it includes ## newer versions of some applications which may provide useful features. deb http://deb.debian.org/debian buster-backports main deb-src http://deb.debian.org/debian buster-backports main deb [trusted=yes] https://deb.torproject.org/torproject.org buster main --Keifer

6 13

response to zimmer family hitting max descriptor size
by code9n＠pm.me 07 May '24

07 May '24

Hi, re. # Questions & Answers * Q: zimmer family hitting max descriptor size https://gitlab.torproject.org/tpo/core/tor/-/issues/40837 Any news on a possible solution to this ongoing issue? tl;dr: more powerful relays rather than large numbers of them. *Please note I have very little idea what I'm talking about here and there's probably something I don't know about or just don't understand. If a family has a very large number of exit relays but the capacity of each one is not that great couldn't they just spend the same money on making existing relays more powerful rather than having more of them? If we're using VPSs then the limits applicable to single cores don't seem to apply the way they do to physical servers. I run a single non-exit relay but I get more traffic through it by having more RAM and multiple vCPUs. The VPS seems to act like it has one large, powerful core rather than the 5 smaller one's it 'actually' has. So if 'descriptors' refer to the number of relays not their capacity wouldn't this work? Side note: to get more bang for your buck you can ask your VPS provider to swap some storage for more vCPUs, that's what I did and it certainly seems to allow me to run more traffic through my one relay. It doesn't need that much storage anyway. So you get the same amount of traffic through fewer, larger relays. cheers,

1 0

Tor Relay Operator Meetup - Saturday, April 13, 2024 at 19 UTC
by gus 07 May '24

07 May '24

Hello, The Tor Relay Operator will happen this Saturday, April 13 at 19UTC! ## Agenda - Announcements: - New Network Health Team lead - 0.4.7 EOL removal - Relay Operator census - Elections 2024: previous (March) / next round (April) - Q&A - Please feel free to add other topics here: https://pad.riseup.net/p/tor-relay-april-meetup-keep ## Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: April 13, 2024 - 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. cheers, Gus -- The Tor Project Community Team Lead

1 2

Ansible for Tor Network Webtunnel Bridges
by Jacobo Nájera 04 May '24

04 May '24

Hi, Share this Ansible role for Webtunnel, with which you can install, configure, and operate Tor network Webtunnel bridges. Currently, it supports installing bridges on Debian, with support for other operating systems coming soon. Repository with the Ansible role for Webtunnel https://github.com/nvjacobo/webtunnel In the Ansible Galaxy repository https://galaxy.ansible.com/nvjacobo/webtunnel A small guide to use the role https://acuare.la/en/ansible-webtunnel-bridges-tor-network/ Feedback are welcome! Thanks, Jacobo

2 3

Is the C tor client DoSStreamCreation aware?
by tor_appliedprivacy.net 28 Apr '24

28 Apr '24

Hello, is the upstream C tor client implementation (in git main) aware of the DoSStreamCreation consensus parameters and defaults thresholds and respects them to avoid triggering these exit relay defenses? If that is currently not the case yet, would it make sense to make it aware so it will never try to create streams at a higher rate? Even if it would be aware already, it would not self limit currently because the current consensus does not enable DoSStreamCreationEnabled. thanks! tor(a)appliedprivacy.net

1 0

Webtunnel type bridge Tor Metrics
by Dionysios K. 25 Apr '24

25 Apr '24

Hello everyone, I recently switched from using obfs4 to Webtunnel from my bridge. Since the configuration change, the metrics website shows it as offline. The downtime displayed on the website is also odd as it shows a random time each time I visit, such as "1 hour 14 minutes and 10 seconds" or "2 hours 23 minutes and 30 seconds." However, the bridge is online. I am wondering if this is the correct behavior for the Webtunnel protocol.

4 5

Re: [tor-relays] Webtunnel type bridge Tor Metrics
by Dionysios K. 25 Apr '24

25 Apr '24

Hey Hiro, The issue was solved for a few hours, it was the first time since I switched to webtunnel I saw my bridge online, but now it's again marked as offline. It's the same issue again. ---------------------------------------- Apr 24, 2024 8:02:02 PM Hiro <hiro(a)torproject.org>: > Dionysios, all, > > This was an issue with rdsys and documents that weren't being synced to the vm where collector.torproject.org lives. > > For details: > > https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/199 > > It should be solved now. > > Talk soon, > > -hiro > > On 4/22/24 22:13, Hiro wrote: >> Hey, >> >> On 4/20/24 17:40, Dionysios K. via tor-relays wrote: >>> Hello everyone, >>> >>> I recently switched from using obfs4 to Webtunnel from my bridge. >>> >>> Since the configuration change, the metrics website shows it as offline. >>> >>> The downtime displayed on the website is also odd as it shows a random time each time I visit, such as "1 hour 14 minutes and 10 seconds" or "2 hours 23 minutes and 30 seconds." >>> >>> However, the bridge is online. >>> >>> I am wondering if this is the correct behavior for the Webtunnel protocol. >> >> The way the metrics website "decides" if a bridge is online is based on both the results of tests from the bridge authority and bridgestrap. If the bridge is working and receiving traffic, the reason why I can think it is marked as offline is that some of those tests is failing or we are failing to process the data correctly. >> >> It could also be that something is a bit off with the bridge configuration since you changed from obfs4 to webtunnel. You could start your investigation by looking at the logs on the machine, then you could check what the bridgestrap stats say about your bridge (https://collector.torproject.org/recent/bridgestrap/) and finally check the latest status (https://collector.torproject.org/recent/bridge-descriptors/statuses/) >> >> Let me know if this helps you. I could also check the bridge myself, you could open an issue on gitlab under the relay-search project (https://gitlab.torproject.org/tpo/network-health/metrics/relay-search) or you can send me a private message (email or irc) with the hashed fingerprint and logs. >> >> Cheers, >> >> -hiro >> >> >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

DoSStreamCreation consensus parameters
by tor_appliedprivacy.net 25 Apr '24

25 Apr '24

Hello, today we saw yet another outbound flooding affecting our exit relays and we were eager to see the effect of https://gitlab.torproject.org/tpo/core/tor/-/issues/40736 but we did not see any and according to metric tor_relay_dos_total{type="stream_rejected"} the protection did not trigger. What are the consensus parameter names for these settings so we can check there current consensus values? > DoSStreamCreationEnabled 0|1|auto > Enable the stream DoS mitigation. If set to 1 (enabled), tor will > apply rate limit on the creation of new streams and dns requests > per circuit. "auto" means use the consensus parameter. If not > defined in the consensus, the value is 0. (Default: auto) > > DoSStreamCreationDefenseType NUM > This is the type of defense applied to a detected circuit or stream > for the stream mitigation. The possible values are: > > 1: No defense. > > 2: Reject the stream or resolve request. > > 3: Close the circuit creating too many streams. > > "0" means use the consensus parameter. If not defined in the > consensus, the value is 2. (Default: 0) > > DoSStreamCreationRate NUM > The allowed rate of stream creation from a single circuit per > second. Coupled with the burst (see below), if the limit is > reached, actions can be taken against the stream or circuit > (DoSStreamCreationDefenseType). If not defined or set to 0, it is > controlled by a consensus parameter. If not defined in the > consensus, the value is 100. (Default: 0) > > DoSStreamCreationBurst NUM > The allowed burst of stream creation from a circuit per second. See > the DoSStreamCreationRate for more details on this detection. If > not defined or set to 0, it is controlled by a consensus parameter. > If not defined in the consensus, the value is 300. (Default: 0) thanks! tor(a)appliedprivacy.net

1 1

I need a new VPS provider
by Landon 23 Apr '24

23 Apr '24

Hello, I am currently using gcore.com as my VPS hosting provider. I have been running a Tor bridge with them for several years now. I am supposed to be getting 200 Mbps unmetered bandwidth. However, in the past six months, my bandwidth usage has been declining a lot. It seems like they might be throttling my server. I was getting over 2000 connected clients and now I'm down to less than 600. "iftop" shows me about 30 to 60 Mbps bandwidth usage during any time of the day. Take a look... https://metrics.torproject.org/rs.html#details/4A0B065DB3CF807C6910DFEF6D9C… So, I am trying to find a Tor friendly VPS provider that offers 1 Gbps unmetered bandwidth. I found my current provider in an article describing Tor friendly providers, but I cannot locate that link. I am currently paying about 15 Euros a month for a server with 2 cores, 4 GB RAM and 100 GB SSD. I would like to pay about the same for my new service. In my search, I have found some better providers, but they don't seem to be Tor friendly. Do you have a good provider that you really like that offers inexpensive VPS? I would prefer one located in the USA if possible, but I guess it doesn't matter if the bandwidth is good. Landon

5 5

tor_bug_reached_count increase
by tor＠appliedprivacy.net 20 Apr '24

20 Apr '24

Hello, the new metricsport counter shows that some specific tor relays (2 out of 50) have a significant tor_bug_reached_count rate (around 8 per second). Do you see similar? You have to run on git main or nightly builds to see that metric. best regards, tor(a)appliedprivacy.net

3 2

issues with tor-nightly-main repo
by applied-privacy.net 20 Apr '24

20 Apr '24

Hello, the repo failed to get new updates after Version: 0.4.9.0-alpha-dev-20240415T020400Z-1~d12.bookworm+1 but we would be eager to test changes that got into main in the last few days. https://deb.torproject.org/torproject.org/dists/tor-nightly-main-bookworm/m… aarch64 build fails. Deploy job is skipped: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/529032 https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/528021 https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/528040 best regards, applied-privacy.net

4 3

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

20 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

issues with tor rpm : anyone sees what I am doing wrong ?
by Carlos 16 Apr '24

16 Apr '24

Hi, lacking competence or support to build bridges under DEBIAN 12, I tried FEDORA and this feeeeeels cool. Yep yet this worry some message : Errors during downloading metadata for repository 'tor': - Status code: 404 for https://rpm.torproject.org/fedora/repodata/repomd.xml (IP: 2620:7:6002:0:466:39ff:fe7f:1826) Error: Failed to download metadata for repo 'tor': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried here is my bash script before the error that I find absolutely fine... kindly prove me wrong, please. Carlos. (would PGP encryption make sense when sending these types of emails to tor-relays(a)lists.torproject.org ? can't see the mailing list PGP publicly) dnf update dnf install dnf-automatic -y systemctl enable --now dnf-automatic-install.timer echo "[tor]" > /etc/yum.repos.d/Tor.repo echo "name=Tor for Fedora $releasever - $basearch" >> /etc/yum.repos.d/Tor.repo echo "baseurl=https://rpm.torproject.org/fedora/$releasever/$basearch" >> /etc/yum.repos.d/Tor.repo echo "enabled=1" >> /etc/yum.repos.d/Tor.repo echo "gpgcheck=1" >> /etc/yum.repos.d/Tor.repo echo "gpgkey=https://rpm.torproject.org/fedora/public_gpg.key" >> /etc/yum.repos.d/Tor.repo echo "cost=100" >> /etc/yum.repos.d/Tor.repo dnf install tor -y dnf install obfs4 -y -- PGP updated every second week : please actualize our communication every time.

3 2

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

09 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

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

05 Apr '24

You should tweak your web server as presented in this section: https://github.com/Enkidu-6/tor-ddos?tab=readme-ov-file#first-step-prep aring-your-system-for-high-number-of-connections This would most likely solve Out-Of-Memory problems I suspect you are experiencing. Denny On 04/02/2024 10:06 AM Alessandro Greco via tor-relays wrote .. My computer has: - 1 vCore CPU - 1 GB RAM - Maximum bandwidth: 1 GB/s So if I understand correctly, the problem should not be at the hardware level, right? Il mar, apr 2, 2024 alle 12:14, Frank LÃ½ via tor-relays <[1]tor-relays(a)lists.torproject.org> ha scritto: Hello Aleff, That is up to you. I strongly suspect that the hardware is the bottleneck, but detailed specifications are required in order to determine a conclusion. Tor is currently bounded by single-thread CPU performance, with a minimum recommendation of 1 GB of RAM for non-exit relays faster than 40 Mbit/s. If your hardware does not meet these RAM requirements, upgrade it, then adjust the relay bandwidth rate limit as necessary. Frank Mar 27, 2024, 7:00 AM by tor-relays(a)lists.torproject.org: > I want to thank you for all the support replies you sent in response to my previous communication. I have carefully read through all your insights and appreciate your efforts in trying to find a solution to the issue. > > After thorough consideration of the matter, I have concluded that the problem may not be due to configuration errors in the automatic updates, as initially speculated. Rather, it seems that the issue could be hardware-related, with my VPS computer potentially unable to handle a certain amount of traffic. > > It's worth noting that there are no bandwidth issues, and the connection speed is high. However, I have set a RelayBandwidthRate limit of 250 Mbits. Interestingly, despite this configuration, the Tor Metrics site detects a speed of approximately 10/13 MBytes, equivalent to about 90/110 Mbits. This led me to speculate that the machine might experience an overload of operations or connections, causing it to crash temporarily. As a result, at the time of restart, Tor Statistics records the maximum speed reached up to that point (without ever reaching the set limit). Subsequently, following this theory, the Tor service restarts automatically without causing any anomalies in the service. > > To address this situation, I have decided to reduce the RelayBandwidthRate limit from 250 Mbits to 100 Mbits, which falls within the minimum limits proposed by torproject. If this is the case, however, it is also true that it would be best to impose an upper limit of 80% when considering the bandwidth magnitude involving the crash event as the maximum point. I honestly don't know how I would be able to verify this and acquire this kind of data, probably doing trial and error is the way. Perhaps the ideal would be to lower the maximum bandwidth further to verify for sure that this is what it is? > > Currently, I am closely monitoring the situation to assess whether this modification has a positive impact on the issue. > > I will keep you updated on any progress, and I thank you once again for your support and understanding. > > Best regards, > > Aleff. > > --- > > 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) > > martedÃ¬ 26 marzo 2024 11:21, torrelay.9puwh--- via tor-relays ha scritto: > >> Hi Alessandro, >> >> It's good to hear from you. I have a relay in a somewhat similar situation[1], although I've only just clocked it. If you're using Debian or one of its derivatives, then you can configure the unattended-upgrades package to perform a restart at a specific time if required. This means that your relay won't restart every time an upgrade is required, but will keep itself up to date. I think configuring a time for a daily restart (if upgrade required) would be a fairly good balance between stability and reliability. >> >> See what other people say or from your own experience, as Tor circuits are generally quite resilient and as long as you aren't a guard node I believe connections won't die because your relay is restarting. >> >> I would also note that Tor recommends [2] an uptime or 24/7 is nice, but not required and that restarts to the daemon or node are fine. Because of this, it might not be worth worrying too much about this issue. >> >> I hope you find some of this useful, >> Seth >> >> >> >> [1] https://metrics.torproject.org/rs.html#details/5FEB80D4DCC63180CB4D8 7C1222177BB099E55AE >> [2] https://community.torproject.org/relay/relays-requirements/ >> -------- Original Message -------- >> On 26/03/2024 08:54, Alessandro Greco via tor-relays tor-relays(a)lists.torproject.org 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)_______________________________________________ >> > tor-relays mailing list >> > tor-relays(a)lists.torproject.org >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays 1. file:///tmp/.webmin/reply_mail.cgi?new=1&to=Il

2 1

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 30 Mar '24

30 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

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 08 Mar '24

08 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