- tor-relays - lists.torproject.org

Re: Programmatically determine if a relay is hibernating
by forest 17 Sep '26

17 Sep '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Roger Dingledine wrote: > I just tested by configuring a controlsocket and it seems to survive > hibernation too. If yours doesn't, please file a bug -- but make sure > that it isn't a Stem bug first. This is Tor on Debian, installed using the Tor Project repos, so surely it's not just a bug. It appears Tor isn't even creating /run/tor/control if it starts up and hibernates, although /run/tor/control.authcookie is created. There is nothing at all unusual in my torrc, and the control socket is created using the tor-service-defaults-torrc that is shipped with the Debian package from the Tor Project repo. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqvxwwAKCRAw+TRLM+X4 xtwZAQDojoUBYui8M+3Ll+ilkjphT0mKfoZODCNeBdLN4UgxPgEAtC1cT3GmDBOQ Q8gi0dxQ+Pr038s+vDbmMQCaYm62xAE= =zpjV -----END PGP SIGNATURE-----

1 1

Should I switch my guards to exits?
by boldsuck 16 Sep '26

16 Sep '26

Background: At the time, our AS was generating ~25% of the exit traffic. I then configured one server with 40 exit relays and another with 40 guard relays. We are now only generating ~16%. https://nusenu.github.io/OrNetStats/#autonomous-systems-by-cw-fraction It’s actually a real shame that the abuse-resistant IPs¹ don't handle exit traffic. In addition, my exit policy is very open. reject *:25 accept *:* ¹f#ck y all > /dev/nulll -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

2 2

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

16 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-----

5 13

Family-ID for bridges
by boldsuck 16 Sep '26

16 Sep '26

Hiho, I'm unsure whether I should apply a "Family key" to my bridges. - tor-spec says: we get bridge families "for free" https://spec.torproject.org/proposals/321-happy-families.html#a-note-on-bri… - hiro says Serge & rdsys is not ready yet: https://forum.torproject.org/t/tor-relays-does-c-tor-support-happy-family-o… I don't mind. I would like to change the bridges from ciissversion:2 'proof:dns-rsa' to ciissversion:3 'proof:dns-familyid-ed25519'. Because I don't know how much longer nusenu will continue to support 'proof:dns-rsa' on OrNetStats. - mikeperry suggests against that we have family sets that includes both the bridges and (at least) exit: https://gitlab.torproject.org/tpo/core/tor/-/work_items/40935#note_3351211 Mmmh, should I publish one family key for bridges and another for relays? I assume _Hidden_ Bridges won't get one. ;-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

3 2

DDoS solution for Tor nodes - nftables variant implemented
by Toralf Förster 13 Sep '26

13 Sep '26

I eventually managed to have it [1] for nftables too and will continue to maintain both variants. The iptables Readme is moved to [2]. Give it a try. Thx -- Toralf [1] https://github.com/toralf/torutils#the-rule-set [2] https://github.com/toralf/torutils/blob/main/README-iptables.md

3 5

Complete list of Tor Metrics keys
by forest 12 Sep '26

12 Sep '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. In order to analyze the ongoing DDoS attack, I'm collecting metrics data from my relays. It's a lot of data so I'm compressing it with zstd. I need a "dictionary" containing a typical metrics output in order to get a better compression ratio. The best I have comes from: curl -s 127.0.0.1:9035/metrics | sed 's/ [0-9]*$//' > dict This creates a decent dictionary with sensitive information (the actual sample values themselves) removed. But from what I understand, Tor only outputs metrics that are relevant, so a relay that doesn't also host an onion service will never have a line starting in "tor_hs_", for example. I'm looking for a sample containing all possible metrics strings, as if Tor did not remove entries that are unrelated to its current state. It doesn't seem like the source code contains anything like that in one easily-accessible location. Does anyone know where I can get this? Regarding the privacy issue of storing metrics data, the relay will be automatically encrypting it with a public key so the relay itself never retains more than a few minutes worth of sensitive data in memory. The metrics will only be used to try to learn more about the ongoing DDoS. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqTkCQAKCRAw+TRLM+X4 xokFAP4snthWGiMg8KXz318kibVVyBZhUIBlOUhVAaC4SuG2NwD/ZQThLAMQFUxP mAm6PbE68Hk91vvxQq9cr6ySYwjlCwc= =ck/7 -----END PGP SIGNATURE-----

1 0

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 28 Aug '26

28 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 25 Aug '26

25 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