- tor-relays - lists.torproject.org

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

Heads up: anti-censorship tools now packaged on deb.torproject.org
by Micah Anderson 01 Aug '26

01 Aug '26

Greetings, We're currently preparing 4 new Debian packages to be included in the Tor Project Debian repository hosted at "deb.torproject.org" in the coming days: * lyrebird * webtunnel * snowflake-proxy * snowflake-client If your system is configured with "deb.torproject.org" in your APT sources and any of the above packages are installed from the regular Debian archive, they will automatically upgrade the Tor Project-published versions. We're doing this to ensure that downstream users of these important anti-censorship tools have an update channel that allows them to receive timely upgrades automatically. That being said, packages from both channels should remain compatible and interchangeable. If you encounter any issues with them, please let us know by creating an issue in https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items. If you wish to add "deb.torproject.org" in your Debian system's APT sources, please follow the instructions at: https://support.torproject.org/little-t-tor/getting-started/installing/#deb… -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

2 1

reply to: 5 to 10 times more outgoing than incoming traffic
by code9n＠pm.me 01 Aug '26

01 Aug '26

Update: re. 5 to 10 times more outgoing than incoming traffic on relay : 6AD7A3E682FE74BDFE34AC0F0D17714480BA773B About an hour after the large difference between incoming and outgoing it had quietened down to about 7MB each way. By two hours after that it is up to around 20MB each way - so I guess it's sorting itself out. I'd be interested if anyone has any idea what happened, though. thanks, Pete

6 5

about vanguards
by Markus Reichelt 31 Jul '26

31 Jul '26

Hi, I do wonder if https://github.com/mikeperry-tor/vanguards is deprecated/dead/no longer needed. Already asked on IRC but got no reply. And then there is https://github.com/mikeperry-tor/vanguards/issues/99 Thanks for any pointers.

1 0