- tor-relays - lists.torproject.org

Abnormal Firewall-States since 0.4.9.10
by ProSecureRelays 19 Jul '26

19 Jul '26

Hi there, I want to report abnormal Firewall States since the update. Since a week or two, (I believe with 0.4.9.10) tor started to excessively use Firewall-States, far beyond what I observed beforehand. In normal operation, I observed about 20k - 45k Firewall States for the relay. Yesterday, before I installed the update, I had 190k Firewall States, related to Tor Relay Traffic. The days before it cycled from 120 - 145k States. Also far more than normal. Today, I see excessive Errors (> 20 Errors/Sek) in my Firewall, relating to use of invalid Firewall States (pf: BAD State..) - all are Tor Related Connections. It would be nice if anyone could have a look, if your connections increased also that much. I also wonder if this might be a type of attack? Regardless of the odd connections, the relay is running well, no CPU peaks and normal memory usage (602MB). Best regards and have a nice weekend! Joker

4 5

adaption of a DDoS prevention solution (now with images)
by Toralf Förster 19 Jul '26

19 Jul '26

Recent DDoS attacks caused me to update the DDoS solution [1] and to roll it out to Tor instances using [2]. The metrics below shows the effect for the (highly overloaded vCPU before), the throughput and the amount of protocol violations of a tiny Tor cloud instance: Another example is Tor instance at a bare metal server, attacked between 12 and 13 UTC (no Tor metrics during that time) and again after 16 UTC. The new rule set was developed between 14 and 15, and fully applies after a reboot at 15:20: The graph below shows that the ipset (which holds malicious ip addresses to be blocked) was not updated at 12 UTC. But with the new rule set in place it was updated soon at 16 UTCk. The green line here is the (now first half) of the changed rule whilst the yellow line reflects the addition for that rule. And finally a graph of the DOS Tor metric for this instance which shows that the Tor process has much less DOS to handle than before: I'm still fine tuning the solution. [1] https://github.com/toralf/torutils#the-rule-set [2] https://github.com/toralf/tor-relays -- Toralf

1 0

5 to 10 times more outgoing than incoming traffic
by code9n＠pm.me 18 Jul '26

18 Jul '26

Hi, re. guard / middle relay : 6AD7A3E682FE74BDFE34AC0F0D17714480BA773B Until yesterday I was getting a normal balance of about 25MB coming in and going out. But today I'm getting around 10MB incoming and averaging about 75MB going out. Any idea what's going on and how to fix it assuming a fix is necessary? Thanks.

1 0

Onionoo shows family_cert but no family_ids
by rE-Bo0t.bx1 17 Jul '26

17 Jul '26

I’m seeing an Onionoo issue with one relay and wanted to check if others have seen it too. Relay: * Nickname: ShinobiHouou * Fingerprint: 7E87EC2F20A371E32E6672A6D04B55471BC5D369 * Tor: 0.4.9.11 * FamilyId: K620zs7GW3AqmEOzvkGYJE/D5HsWrOrmDlckrhxbrXE The relay has been online since 2026-07-11. Onionoo updates last_seen normally and the relay is reachable on IPv4/IPv6. The rest of my Shinobi relay family shows family_ids in Onionoo. This is the only one missing it, out of 15 relays. Onionoo’s full details document includes family_cert: |curl "https://onionoo.torproject.org/details?lookup=7E87EC2F20A371E32E6672A6D04B5…" | jq| Relevant part: |"family_cert": "AQwAB5K5AfR4C6AIeIu0XUQn5Td+xHll8Hon3vGRqcKUZIfD6YFbAQAgBAArrbTO..."| But this still returns no family_ids: |curl "https://onionoo.torproject.org/details?lookup=7E87EC2F20A371E32E6672A6D04B5…" | jq| Output: | { "relays": [ {} ] }| 1AEO also detects the relay as Happy Families, but keeps it under “Pending Onionoo refresh”. https://metrics.1aeo.com/relay/7E87EC2F20A371E32E6672A6D04B55471BC5D369/ So it looks like Onionoo sees family_cert, but does not derive/expose family_ids for this relay. I found what looks like a similar earlier tor-relays/forum thread: https://forum.torproject.org/t/tor-relays-onionoo-relays-with-family-cert-b… Is this expected/known behavior, or is there a way to debug why family_ids is absent even though family_cert is present in Onionoo? Any hints or sanity checks would be appreciated. rE-Bo0t.bx1 https://relays.brokenbotnet.com

1 1

Experiences running a Tor exit relay in Serbia (or with MAXKO)?
by Beacon Tor Node 17 Jul '26

17 Jul '26

Hello everyone, I'm planning to run my first Tor exit relay and I'm looking at hosting it in an underrepresented location. According to Tor Metrics there are currently no exit relays in Serbia at all, so I'm considering a Serbian location with the provider MAXKO (a Croatia-based company, AS211619). Before I commit, I'd be grateful for any experience or advice on two points: - Has anyone run a Tor exit relay hosted in Serbia? Any legal or practical issues to be aware of, given Serbia is outside the EU (no "mere conduit" protection)? - Does anyone have experience with MAXKO as an exit-friendly host, in particular how they handle abuse complaints and whether their Serbian location runs under a separate AS? I plan to run a reduced exit policy, a proper abuse contact and a notice page on port 80. Thanks a lot for any input! Best regards

2 1

Tor Metrics
by wxw＠safe-mail.net 14 Jul '26

14 Jul '26

Hi I have operated many relays over the years. I only started using tor metrics to check up on my relays for maybe 3-5 years. Over the last year I have noticed that my uptime has reset randomly sometimes every couple of days sometimes every couple of weeks. When I first started they were up for months at a time. Now I know what you may be thinking that my relays are just going down for whatever reason. Well that's not the case as I do monitor them independently also. The thing is they all go out and reset the uptime at exactly the same time. Now I use 3 separate vps providers for 17 middle relays. When I go to check them they all are showing the exact same new uptime. Can you help me to understand this. Thanks a lot for all that you do. Regards Phil (search masstor relays)

3 2

Spam to relay address after three months
by Andrew J. Caines 13 Jul '26

13 Jul '26

The email address used for the HALTor relay was first published in the configuration on 3 Apr 2026. The first spam received at this address arrived 1 Jul 2026, ninety days later. This isn't a complaint or request for support or advice, just sharing the observation that even in the middle of this year of our Lord two thousands and twenty-six, scraping is still practiced... that is, unless there is some record of relays containing these addresses which has been published - intentionally or not. -- -Andrew J. Caines- Unix Systems Architect A.J.Caines(a)halplant.com "Machines take me by surprise with great frequency" - Alan Turing

2 1

Tor relay doing 400 Mbps up, 50 Mbps down until reboot
by forest-relay-contact＠cryptolab.net 12 Jul '26

12 Jul '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. One of my relays, 54C85B97B4A5253483AA269B341C4CCF9328C443, had 400 Mbps up and only 50 Mbps down for several hours. Performance got so bad that could barely SSH in. Unfortunately, I rebooted before doing diagnostics and the problem has not happened since, so I couldn't see if Tor logged asymmetric bandwidth use in its heartbeat. Nothing in the logs indicate anything abnormal. This started on Jun 25th, 12:30 AM UTC and continued until I rebooted at around 4:00 AM UTC. Tor's CPU use was 100% for the duration of this event and the uplink was not saturated. Is this something that has happened before? Could it be some DoS attack? As far as I know, the only way to get Tor to use asymmetric bandwidth is to use it as a directory mirror. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaj2vuwAKCRAw+TRLM+X4 xhhPAQDqw7+xxZWmOUP00rTmyT1brTFdkTRwEUWWmSdx1njWLAEA8lttz57jLKO7 zZSJyBW02z8rMKds0SpRiP2heVBfFwQ= =ecuY -----END PGP SIGNATURE-----

2 1

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

01 Jul '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 7

GeoIPFile option warning
by krishna e bera 27 Jun '26

27 Jun '26

I am seeing these warnings in Tor's notices.log: Mar 24 09:42:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Mar 24 09:42:21.000 [notice] Configured to measure entry node statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. However the option is set in torrc and i verified the files are at those locations and readable by all: GeoIPFile /usr/local/share/tor/geoip GeoIPv6File /usr/local/share/tor/geoip6 Any hints how i could check whether the warnings are spurious or dump what the running config actually is? I know it is reading the torrc because introducing an error in the file stops it from loading.

2 3