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

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

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

The tor-realay-list and the tor-ddos project will soon go down
by Chris Enkidu-6 03 May '26

03 May '26

Due to a serious Illness Soon I will not be able to maintain that list anymore. Without that list the Enkidu-6 Tor-DDOS iptable lists will become useless because they all point to the tor-relay-lists. I'm looking at someone established with enough resources to maintain that list and I'd be glad to offer them the source code for how I get that list. You'll just need to associate your PGP key with your Github account and hopefully have at least two separate servers to run the Cron job on. Any dedicated takers please let me know. The whole thing will go down in probably a couple of weeks. Thank you all for taking the time to read my post.

3 2

confirming onionoo/CollecTor issues vs. Happy Family relay misconfiguration
by nusenu 29 Apr '26

29 Apr '26

Hi, I've been contacting relay operators to verify suspected CollecTor/onionoo issues that appear since CollecTor got replaced in early April. To scale a bit better I'm sending this email to the tor-relays list + BCC instead. In most cases so far it turned out to be an onionoo issue but I see some slow improvements. If you are one of the operators listed below it would be great if you could help verifying your config and confirm if - this is indeed an onionoo issue (all your relays found by the onionoo URL below should have the same Happy Family configuration but according to onionoo do not) - or an inconsistent Happy Family configuration on your side: not all your relays have Happy Family configured (not an onionoo issue) - they are not actually your relays - in this case you can report them for removal to the bad-relays team if they use your contact information With your help we can get a better overview of the current onionoo / CollecTor situation. I noticed unexpected (missing) family_ids on relays using this CIISS url value: alxu.ca doedelkiste.de germancraft.net torix-relays.org tuxli.org for-privacy.net emeraldonion.org www.1aeo.com example onionoo URL for doedelkiste.de: https://onionoo.torproject.org/details?contact=doedelkiste.de&fields=family… You can simply replace the contact parameter value with your domain. You should be able to spot suspicious lines in the output because these lines are shorter (no family_ids string included). thanks for your help! nusenu -- https://nusenu.github.io

2 2

CollecTor has been rewritten in Rust and is now live
by Silvia Puglisi [Hiro] 28 Apr '26

28 Apr '26

Hi everyone, We've rewritten CollecTor from the ground up in Rust, replacing the legacy Java service that has been increasingly unstable over the past months. The new service, collector-rs, was deployed yesterday and is now live. You can find the source at: https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs Shoutout to Juga who has been the main developer behind the redesigned service. A couple of things to be aware of: - Data continues to be available in the usual folders, so existing workflows should not be affected. - You may notice some folders are temporarily duplicated as part of the transition. This is cosmetic and the underlying data is consistent. - The instability of the old CollecTor may have affected services that depend on it as an upstream data source, including Onionoo, Tor Weather, the metrics website, and any community-run services or apps that consume CollecTor data. The new deployment should resolve these issues going forward. If you run into any issues or notice anything unexpected, please don't hesitate to reach out or open an issue on the GitLab repo. Cheers, hiro

2 2

relayor v26.1.0 is released with CPU affinity and flexible instance count
by nusenu 28 Apr '26

28 Apr '26

Hi, relayor v26.1.0 is released. If you upgrade from previous versions to this release please read the Upgrade Steps before upgrading (minor breaking change): https://github.com/nusenu/ansible-relayor/releases/tag/v26.1.0 relayor is an ansible role that helps you with automating tor relay operations https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… New features ------------ - support arbitrary instance count per server - add CPU affinity support (Linux/systemd only) - when enabled each tor instance is bound to a distinct logical CPU core (disabled by default) - support CIISS v3 Happy Family based proof file generation (drop v2 proof files support) Bugfixes -------- - generate prometheus scrape configurations with correct starting section in YAML - FreeBSD: use py311-passlib instead of py39-passlib Changes ------- - kitchen: remove debian oldstable from kitchen platforms kind regards, nusenu -- https://nusenu.github.io

1 0

HSDirSniper
by Logforme 25 Apr '26

25 Apr '26

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 and saw something new in the log: Apr 24 15:29:38.000 [notice] HSDir cache exceeded limit (1338107635 > 1338067189 bytes). Pruned 50060715 bytes during an HS descriptor upload. Apr 24 16:18:02.000 [notice] HSDir cache exceeded limit (1338072160 > 1338067189 bytes). Pruned 50030005 bytes during an HS descriptor upload. [1 similar message(s) suppressed in last 2640 seconds] Apr 24 17:04:36.000 [notice] HSDir cache exceeded limit (1338085370 > 1338067189 bytes). Pruned 50018816 bytes during an HS descriptor upload. Apr 24 17:50:54.000 [notice] HSDir cache exceeded limit (1338083686 > 1338067189 bytes). Pruned 50017100 bytes during an HS descriptor upload. Apr 24 18:41:29.000 [notice] HSDir cache exceeded limit (1338071628 > 1338067189 bytes). Pruned 50005672 bytes during an HS descriptor upload. Found the message in the source for Arti (which I'm not running): https://tpo.pages.torproject.net/core/doc/tor/relay_8c_source.html. Also found this paper: https://dl.acm.org/doi/epdf/10.1145/3589334.3645591 Did someone just HSDirSnipe against my relay? Does the messages indicate Tor handled it? Anything I should do in my configuration?

1 0

bridge in limbo after new ip assigned
by mossy_road_523＠protonmail.com 24 Apr '26

24 Apr '26

I run an obfs4 bridge. The bridge had been up, operational and carrying (light) traffic for almost 60 days when my ISP assigned me a new address. I wasn't able to repair the bridge for 4 or 5 days. When I did get to it, I registered with a DDNS service, and in my torrc I replaced the hard coded IP with the new domain name I registered. After making that change I restarted the bridge. Logs all looked fine, it booted up to 100%, and reported that the IP was externally reachable (Excellent!). It has been running for 5 days now. It frequently reports having 20 or 25 circuits open (mostly hs_vanguards and conflux_linked; occasionally a "General" purpose circuit). Traffic has been extremely sparse. Even though the bridge seems healthy from my end, I get mixed results from the external checks: * Tor Metrics Relay Search site says the bridge is down, and shows 0 bytes moved and 0 users for the past many days. * bridges.torproject.org/status page always report the bridge as "dysfunctional." * Tor Project Tor Reachability Checker always reports "TCP port is reachable!" I don't mind the "broken" status pages so much, but the fact the bridge itself reports carrying very little (although non-zero) traffic has me concerned. Can any one shed any light on what might be happening, what I could try to further debug this, etc.? Happy to provide snippets of my torrc or any other info that might be helpful. Bridge id is 744DA6E2E2BCB93999C8B16C1C185BA06DFFA447 Tor Metrics page for the bridge: https://metrics.torproject.org/rs.html#details/744DA6E2E2BCB93999C8B16C1C18… bridges-status site: https://bridges.torproject.org/status?id=744DA6E2E2BCB93999C8B16C1C185BA06D… Thanks much for any help.

1 0

Please update standalone snowflake proxy to v2.13.1
by Cecylia Bocovich 20 Apr '26

20 Apr '26

Hello, After receiving reports of Snowflake proxies being blocked by DTLS fingerprint in Russia[0], we updated the standalone proxy to enable a new DTLS randomization and mimicry feature[1] by default. Proxy operators that are using the standalone version of the proxy will need to update or set the following command-line option: -covertdtls-config randomizemimic Browser-based proxies such as the browser badge or webextension were not blocked and do not require an update. Thank you for running a Snowflake proxy! [0] https://github.com/net4people/bbs/issues/603 [1] https://www.petsymposium.org/foci/2025/foci-2025-0006.pdf

6 6

relay listed as ipv6-reachable but isn't
by Marco Moock 17 Apr '26

17 Apr '26

Hello! I am referring to https://metrics.torproject.org/rs.html#details/BBBBBAD453263D786EC34AB68A06… I cannot reach this relay via the IPv6 address, a tcp traceroute to port 443 ends at 2a00:6020:ffff:ffff::14. Can someone explain why this is listed as reachable in consensus? -- kind regards Marco Send spam to 1776365568muell(a)stinkedores.dorfdsl.de

2 3