- tor-relays - lists.torproject.org

How is this attack causing 900 Mbps download and 100 Mbps upload?
by forest 10 Sep '26

10 Sep '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I'm experiencing a very strange high-bandwidth attack against my exit F79C822281CB1001E589296C80ABA6EA5DC7E36A. At first it was a directory fetch attack, slowing it to a crawl due to upload exceeding 700 Mbps (while download was never over 50 Mbps). I added "DirCache 0" to torrc as a stop-gap measure, but after reloading, the attack has changed and now *download* is excessive, showing 900 Mbps down and 100 Mbps up. How is this possible? What kind of attack could cause such asymmetric load in the *download* direction? I confirmed with nyx that it was downloading at nearly 10x the rate that it was uploading. This relay rarely exceeds 100 Mbps bidirectionally under normal conditions. Of the 60 relays I operate, this is the only one that appears affected. I'm urgently in need of advice for troubleshooting this. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqCn9gAKCRAw+TRLM+X4 xuy7AQCmmd6TvF4MSr8c04pbHVl3Emw0SufRO0Vxg4XFnz7jtQEAnE7u4Y653gn6 vdzmiDOP9VJT9fDDSP4LXqu64XHh9gE= =9jHQ -----END PGP SIGNATURE-----

3 3

PSA: 0.4.8.x is EOL now, please upgrade!
by Georg Koppen 02 Sep '26

02 Sep '26

Hello! As a reminder for those of you still running any 0.4.8.x Tor version (be it as a relay or a bridge): please upgrade! The 0.4.8.x series is end-of-life since 2 days ago and you should see a respective warning in your Tor log since yesterday. There's currently still 1598 relays on 0.4.8.x, which means roughly 19% of the advertised bandwidth of the network (and 990 bridges). Supported releases in general can be found on the network team wiki.[1] As for the timeline, we plan to reach out to operators still not having upgraded by start of August, and 0.4.8.x is on track to get blocked from the network early September.[2] To follow along the EOL process for 0.4.8.x you can track our work in Gitlab as well.[3] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… [2] We have a ticket for blocking clients by then: https://gitlab.torproject.org/tpo/network-health/team/-/work_items/460 [3] https://gitlab.torproject.org/tpo/network-health/team/-/work_items/453

1 1

Snowflake setup fail
by John Thompson 29 Aug '26

29 Aug '26

Repeated blacklisting while running a tor relay has persuaded me to try a snowflake proxy instead. I want to run a stand-alone proxy on Almalinux-9.8. Following the instructions on https://community.torproject.org/relay/setup/snowflake/standalone/docker/, I have installed docker, but cannot complete the next step, downloading the docker-compose.yml configuration file: $ wget -O docker-compose.yml https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… --2026-08-21 09:17:57-- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Resolving gitlab.torproject.org (gitlab.torproject.org) 2620:7:6002:0:266:37ff:feb8:3489, 204.8.99.149 Connecting to gitlab.torproject.org (gitlab.torproject.org)|2620:7:6002:0:266:37ff:feb8:3489|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2026-08-21 09:17:57 ERROR 403: Forbidden. Is there a fix? -- -John Thompson (johndthompson(a)gmail.com) Appleton WI USA

6 16

False-positive abuse reports from XMission's exit relay made against other relays
by forest-relay-contact＠cryptolab.net 26 Aug '26

26 Aug '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. An ISP in Utah, XMission, runs their own Tor exit under the fingerprint E3DB2E354B883B59E8DC56B3E7A353DDFD457812. Their exit has been running for 14 whole years! But in the last few years, they appear to have added an AbuseIPDB auto-submitter script that reports any UFW blocks to AbuseIPDB, even if those come from fellow relays. I'm sure a lot of you have seen xmission appear as a reporter against your (middle and exit) relays on AbuseIPDB with a reports such as: > Blocked by UFW (TCP on 36972) Source port: 9001 TTL: 47 Packet length: > 2276 TOS: 0x08 This report (for 89.125.139.145) was generated by: > https://github.com/sefinek/UFW-AbuseIPDB-Reporter I've tried contacting their support and they may be slowly realizing what the issue is, but I (and others) have already had relays suspended by our hosting providers because of XMission's false reports, and they do not appear to be doing anything about it anytime soon. What can be done about this? At this rate, I'll have to shut a number of my own relays down because of their false reports. The only other thing I can think of is to block their IP, but I know that that's not good practice. Is it a necessary evil in this case? Could someone from Tor Project possibly reach out to them and explain that their relay is auto-submitting false positive abuse reports against other relay operators, if I'm unable to get through to them? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCao5ARwAKCRAw+TRLM+X4 xsRVAP9nr/n4linFzJDSDnayuR4z8ZI83E7UsT6Mx1W4v+1fLQEA8vfxAOQm1R+2 liyMtXCw/cEyvUFto+1m0TBZMUaPywI= =gyrl -----END PGP SIGNATURE-----

1 1

Why is my MTBF so low?
by tor.kmv82＠simplelogin.fr 24 Aug '26

24 Aug '26

Hello, my relay (https://metrics.1aeo.com/relay/3E55EA525E5FB323485EB55EC4D2586BD81AE20D/) currently has a stable uptime of 16 days. However, all directory authoritys, except moria and longclaw show a MTBF of 0.6 days-1 days. Some other relays in the AS of contabo (AS51167) seem to have a similar discrepancy between the uptime and the MTBF. The following relays have a similar MTBF for all dirauths, except moria and longclaw, despite reporting a higher uptime: https://metrics.1aeo.com/relay/19996F2316028917860E6264B0CFCBFA76BEDB62/ 32 days uptime, MTBF 0.7-1.4 days https://metrics.1aeo.com/relay/2A9617210F42738F14D0CFE0AF9C50E7CBB355FC/ 88 days uptime, MTBF 0.7-1.2 days https://metrics.1aeo.com/relay/75853C2AA60EAF038A070158341CBDB3ADC717CB/ 13 days uptime, MTBF 1.1-1.5 days https://metrics.1aeo.com/relay/DB986755D9ED77778C0F2D4E497EFB4CAF62A787/ 57 days uptime, MTBF 0.9-1.1 days Is there anything i can do to ensure that my relay is more stable/ or how i can debug why my relay seems to have sometimes issues to connect with the dirauths?

2 1

for tiny tor instances: 3 Tor config values worth to try out
by Toralf Förster 12 Aug '26

12 Aug '26

Based on advises here and there I configured my tiny Tor relays (1 vCPU, 1 GiB RAM) with these values: - name: DosCircuitCreationBurst value: 20 - name: MaxOnionQueueDelay value: 1000 - name: MaxMemInQueues value: 320 MB and it seems to help (beside the iptables solution ofc). -- Toralf

2 2

OT: How much Internet traffic overall is from Tor?
by Lars Noodén 07 Aug '26

07 Aug '26

Greetings, Are there any recent data estimating the percentage (or absolute volume) of Internet traffic which is from Tor? I suppose these metrics have been covered at some conferences now and again, but I cannot find anything other than comparisons of HTTP vs HTTPS or HTTP 1.1 vs /2 and /3. Decades ago, there used to be sites tracking the portion of traffic used by various protocols. The WWW (aka HTTPS and HTTP) has lately overwhelmed global mind share, such that it is now all but impossible to find mention of any other protocols, let alone traffic statistics. But I expect there are still measurable amounts of traffic with other protocols e.g. Tor, I2P, SSH, BitTorrent, Gopher, Gemini, RTSP, etc. FTP, WAIS, and Telnet are probably gone, thankfully. Which list would have been the right one to ask this? /Lars

1 0

Tor activities at Defcon
by Roger Dingledine 06 Aug '26

06 Aug '26

Hi folks! Many Tor people are here at Defcon this weekend. You can find us at: (1) Our booth, in the non-profit vendor area near EFF and others. People will be there Friday Saturday Sunday during daytime hours. Check out the cool new keychain onion plushies, or ask questions or answer questions. (2) A Friday evening "Tor Social Hour (but really two hours!)" at the Golden Monkey Tiki Lounge, inside Resorts World, 7pm to 9pm. It is BYOB (buy your own beverage) -- come say hi, meet Tor staff and community. (3) I have a talk super early on Sunday (0930 in the War Stories track), where I'll talk about past/present/future challenges with keeping the Tor network safe and working, both from the user perspective and the relay operator perspective. After the talk I plan to bring everybody to the booth for AMA / Q&A until everybody is out of questions. We didn't manage to schedule an official relay operator meetup this year, but I am thinking of trying to organize one next year as a slot in the privacy village. When you find me, please let me know if this is a good idea or a bad idea. :) --Roger

1 0

Post-Quantum Cryptography in Tor's TLS Layer: Help needed!
by Alexander Hansen Færøy 06 Aug '26

06 Aug '26

Hello Tor Relay Operators, With the arrival of OpenSSL 3.5.0 in 2025, we finally had an important missing piece of infrastructure to start enabling the Tor network to support Post-Quantum Cryptography in the outermost cryptographic layer of the Tor protocol. Since Tor version 0.4.8.17, we have supported the x25519/ML-KEM-768 hybrid handshake in our TLS layer, and we have gradually seen more relays supporting it in the production network. Tor Browser has been built against OpenSSL >= 3.5.0 since (at least) version 13.5.22, released in September 2025, and therefore supports Post-Quantum TLS handshakes today, but it requires that its guard node supports it. We need to give a big shout-out to the OpenSSL Team here to get this out and available to the masses! <3 Since Q3 2025, I've been running some semi-regular scans of the Tor production network to check for TLS cipher suite availability. This work started as part of the first Tor Community Gathering back in October, 2025[1]. The results are as follows: In January, around 28% of the Tor relays supported the Post-Quantum TLS handshake. The scan I did yesterday showed an increase of around 4 percentage points to 32.32%. Out of 9476 scanned relays, 9185 were reachable, 291 were unreachable. Of the 9185 reachable relays, I saw the following distribution of cipher suites: `TLS13_AES_256_GCM_SHA384`: 9023 relays. `TLS13_CHACHA20_POLY1305_SHA256`: 158 relays. `TLS13_AES_128_GCM_SHA256`: 4 relays. For the key exchange groups, I saw the following distribution: `secp256r1`: 6212 relays. `X25519MLKEM768`: 2969 relays. `X25519`: 4 relays. Of the Directory Authorities, 5 of them supported the `X25519MLKEM768` key exchange group during the TLS handshakes. 2969 / 9185 * 100 = 32.32% of relays support the `X25519MLKEM768` cipher suite. This number is a good start, but we should ideally bump it up! You can see the individual results for your relay(s) in the big table available at https://ahf.me/tor-tls-pqc/2026-02-26/ -- entries without a cipher suite or key exchange group were unreachable at the time I ran the scan. These missing entries can be due to a network problem anywhere on the path between my host and yours, so don't get worried if your relay is missing :-) The scanner I used is free software and is available as part of the Network Health Team's Margot tool[2], used for various analysis purposes. Please note that the goal here isn't to enumerate all available cipher suites for each relay, but instead I'm interested in the "strongest" possible cipher suite my custom client can negotiate with each relay. My ask for you as the relay operator community here is as follows: Next time you folks are doing maintenance on your relay(s), please have a look at whether you can upgrade either your packages or underlying software distribution to a version such that you either get a new enough version of OpenSSL (>= 3.5.0), or if you are a LibreSSL user, check whether the LibreSSL project supports the ML-KEM hybrid handshake, and upgrade to that version. It looks like the LibreSSL project is currently working towards supporting the ML-KEM handshake in the next upcoming release[3]. For Debian users, to get a new enough OpenSSL version that supports the PQC TLS handshake, you need to upgrade to (at least) Debian Trixie. For everybody else, it's best to check your respective software distribution's package management system to find the version you need to upgrade to. For Arti users, a licensing issue with the currently available crypto providers in Arti prevented enabling the ML-KEM handshake. Nick, however, has recently been making progress on this matter and has a patch up that is now pending upstream review[4]! :-) If you are excited about exploring different aspects of the Tor ecosystem, talking with other Tor enthusiasts, and you have nothing planned for your weekend in two weeks, I highly encourage you to look into the next Tor Community Gathering in Denmark. The event takes place from 2026-03-13 to 2026-03-15. For more information, check out our website at https://onionize.space/2026/ Thank you all for all the work you do to make Tor better! <3 Cheers, Alex [1]: https://onionize.space/2025/ [2]: https://gitlab.torproject.org/tpo/network-health/margot/ [3]: https://github.com/libressl/portable/blob/a989b7acb9a475fde656e48dbcb38289d… [4]: https://github.com/RustCrypto/rustls-rustcrypto/pull/143 -- Alexander Hansen Færøy

4 8

Tor Relay Crash
by Lavender I Tor Relay 04 Aug '26

04 Aug '26

Hello, I've been tearing my hair out a bit lately. I launched a Tor middle relay a few weeks ago, but every so often, I get a dramatic spike in upload traffic, and the relay becomes almost unusable—or even crashes... I thought it might be a DDoS attack, but I'm not sure. Is something going on with the network right now, or is it on my end? I’ve set the relay’s bandwidth rate to 52 MB and 55 MB burst, but sometimes the upload speed hits 100 MB/s… The relay averages around 10 MB, and then suddenly it runs at 60–100 MB/s for several hours at a time. I already have a UFW firewall that only allows the relay ports on my server. It takes a while to get flags, and since my relay crashes because of these network spikes, I lose a good portion of my flags and basically have to start all over again... It's really frustrating. Thanks

3 4