September 2026 - tor-relays - lists.torproject.org

Looking to interview Tor relay operators (online or at FOSDEM)
by Jules Dejaeghere 16 Oct '26

16 Oct '26

Hello, I am a researcher at the University of Namur (Belgium), and some of our research focuses on Tor. Recently, we started to investigate how Tor relay operators install and keep their relays up to date. This research was motivated by the (somewhat recent) policy of the Tor Project to exclude outdated relays from the network. As part of this research, we would like to interview relay operators to understand how they install and keep Tor up to date and what they think of the Tor Project policy. If you run, or used to run, Tor relay(s) and are willing to dedicate ~30 minutes of your time, let us know! Your participation will inform our current research about how Tor relay operators manage their relay(s). It will also provide community feedback to the Tor Project about their policy once our results are published. Interviews can be done either online (during the week of 2-6 February 2026, via Framatalk https://framatalk.org/abc/en/) or in person during FOSDEM in Brussels (31 January & 1 February 2026, https://fosdem.org/2026) To participate: - Contact me via email (jules.dejaeghere(a)unamur.be, PGP 0xEB4CC38446E3F82F) or Signal (@julesd.01) - Specify how you want to participate (online via Framatalk, or in person at FOSDEM) and what time slots work for you In practice: - The interview will be audio recorded for analysis by the research team - You can stop the interview at any time, and your answers will be deleted - The interview can be held either in English or in French You'll find attached the full consent form we will ask participants to sign, which describes how the data collected will be processed. If you have any additional questions, you can contact me. Regards, Jules Dejaeghere -- *Jules DEJAEGHERE* PhD Student · Researcher Computer Science Faculty jules.dejaeghere(a)unamur.be https://directory.unamur.be/staff/jdejaegh Université de Namur ASBL Rue de Bruxelles 61 - 5000 Namur Belgium Let’s respect the environment together. *Only print this message if necessary!*

6 14

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

13 Oct '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-----

11 26

Family-ID for bridges
by boldsuck 11 Oct '26

11 Oct '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 3

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

10 Oct '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 6

Should I switch my guards to exits?
by boldsuck 10 Oct '26

10 Oct '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!

3 3

FamilyID help...again
by wxw＠Safe-mail.net 29 Sep '26

29 Sep '26

Hi, I have run my relays for 15+ years. I am trying to implement FamilyID by following your instructions at https://community.torproject.org/relay/setup/post-install/family-ids/. I generate my secret_family_key. I save the FamilyID. I copy secret_family_key to my key directory "I think". All servers are Debian 12-13. All tor versions are Tor 0.4.9.12 (recommended). Instructions call for sub-directory of DataDir? I don't know where that is. All my Tor key appear at /var/lib/tor/keys so that is where my secret_family_key is. I add FamilyID #$%^&*()POIUYHJKLetc as in the format line generated to the bottom of my torrc file. I restart relay. (Systemctl etc) I also reboot the whole server too. Nyx won't start. Remove the FamilyID from torrc and everything is fine and Nyx starts. I have regenerated secret key several times, tried adding to 3 different relays with exactly the same results. All my servers have Effective & Alleged Family Members listings obviously. I have 2 questions what am I doing &*(*(**( wrong & do I have to add the FamilyID to all my relays first to get things working? Thanks Phil

3 2

Amplification Attack?
by ProSecureRelays 22 Sep '26

22 Sep '26

Hi there, regarding the current attack on the network, I can only add that my suspicion is some kind of amplification attack. As other operators also noticed, I see normal inbound traffic flows but excessive outbound flows (even exceeding my line rate by far..), when my Guard is under attack. I noticed in my Logs, just before the last OOM Crash of the Tor Process occurred, this warning is spammed excessively: [warn] Service descriptor has an invalid signature length.Expected 86 but got 88 However, the OS did not report any resource exhaustion in that particular moment, and Tor could use ~12GBs out of the 16GB System Memory. That's different from the last crash I had some time ago, where the whole OS triggered resource exhaustion alarms. With the Information others provided (disable Directory Services solves the issue) I would suspect some issue with the services directory, where a malformed request triggers multiple outgoing requests from the relay itself, overloading it in the process. I'm not deep in the functionality of the directory services, but maybe this can be triggered when registering a malformed service or querying the directory with malformed packets. This month my biggest uptime enemy was Microsoft itself, ignoring the GPO's for Update related-restarts and just rebooted twice because of the emergency update that was released. So no more crashes so far. I've attached the Tor Logs when the Relay died, but I don't think it'll help much. Best regards and let's hope for the best! Joker

2 1

overhauled nftables implementation of DDoS prevention solution
by Toralf Förster 20 Sep '26

20 Sep '26

The template [1] works now both for a straight forward Tor instance as well as for machine hosting many Tor instances in parallel. Therere no dedicated firewwall rules per Tor instance. The memory foot print is reduced. And, to avoid wrong abuse complaints from an over-reacting IDS I re-implemented the existing solution [2] in nftables [3]. Will continue to maintain iptables and nftables implementations of the ruleset [4]. As of today metrics show few dozen blocked addresses at a couple of tiny VPS relays, but a high 3-digit number at a bare metal server hosting 5 relays, drop rate is about 40 p/s here. Much higher values were observed in the past. Feedback appreciated. -- Toralf [1] https://github.com/toralf/torutils/blob/main/nftables-ingress.conf [2] https://github.com/toralf/torutils/blob/main/ipv4-rules-egress.sh [3] https://github.com/toralf/torutils/blob/main/nftables-egress.conf [4] https://github.com/toralf/torutils#the-rule-set

1 0

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

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