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

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

17 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

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

Seeking recommendations for pf firewall relays
by zwiebelrouter 11 Apr '26

11 Apr '26

Hello everyone, I am running a few Tor relays on FreeBSD to help diversify the network and use pf as the firewall on my servers to block unwanted traffic. To reduce the impact of possible future DoS attacks, I want to make use of max-src-conn and max-src-conn-rate to limit a single IP address from creating unlimited TCP states, as well as limit how fast new TCP sessions can be created. Due to some other relays running up to eight instances per IP address, I don't want to set the limit too low, so legitimate connections aren't accidentally dropped. So my question to other relay operators using FreeBSD and pf, what values do you use, and ars there other settings I can use to fine tune pf firewall on my Tor relays? Regards, ZR

6 5

CIISS Version 3: Easier proof based on Happy Family ID
by nusenu 28 Mar '26

28 Mar '26

Hi, version 3 of the ContactInfo Information Sharing Specification is ready: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/rel… The most relevant change is the replacement of relay fingerprint based proofs that required updating of the proof when adding new relays. The new Happy Family based proof that does not require any proof update as long as the family ID remains unchanged and all your relays use the same family ID. For OrNetStats https://nusenu.github.io/OrNetStats/ I will likely stop using version 2 and replace it with version 3 within about one month so it is best to switch to version 3 within that timeframe. Here is an example ContactInfo string using the new proof: email:tor[]example.com url:https://example.com proof:uri-familyid-ed25519 ciissversion:3 more details on the new proof options: https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#pro… kind regards, nusenu -- https://nusenu.github.io

2 1

Happy Family Roadmap for ansible-relayor/CIISS/OrNetStats
by nusenu 27 Mar '26

27 Mar '26

Hi, since David mentiond that there will be the first tor 0.4.9 stable release this week and ahf also mentioned [1] ansible-relayor in the context of the MyFamily successor Happy Family I want to give you a short roadmap in the context of relayor/CIISS/OrNetStats: * first stable tor 0.4.9.x release (likely in the coming days) * after tor 0.4.9 reaches deb.torproject.org and FreeBSD packages: * ansible-relayor will require tor version >= 0.4.9 and enable Happy Family by default in addition to MyFamily * after the first tor browser release with tor 0.4.9 for all platforms: * MyFamily support will be removed from ansible-relayor * CIISS version 3 is released: MyFamily is replaced with the Happy Family system * operators will have to update their proofs * we wait for happy family support in onionoo [2] * OrNetStats will implement and verify proofs according to CIISS version 3 [1] https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torp… [2] https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/4… kind regards, nusenu -- https://nusenu.github.io

2 3

Critical Infrastructure Advisory
by jmhbm＠duck.com 20 Mar '26

20 Mar '26

Dear Tor Relay Operators, I am writing to provide a formal advisory regarding an anticipated infrastructure break event scheduled for October 11, 2026 — the ICANN Root Zone KSK rollover. This event is expected to interact with potential vulnerabilities in resolver fragility, hardcoded fallback mechanisms, and encrypted DNS discovery protocols. This advisory is not intended as a routine cryptographic maintenance task. The KSK rollover serves as one of two critical timed “locks” within a broader restructuring of internet infrastructure layers, including DNS, Certificate Authority (CA) governance, and device attestation. The second such lock is the tightening of Android Remote Key Provisioning (RKP) on March 16, 2026, which collectively accelerates the consolidation of essential functions into hyperscaler-controlled systems, with Google positioned to benefit significantly from this shift. Infrastructure Break Mechanism The breakdown follows a predictable sequence of five stages: KSK-2026 and DNSSEC Fragmentation: Dual-signing increases root-zone response sizes beyond the approximately 1232-byte UDP limit. This can cause volunteer-run and containerized resolvers to drop fragments or fail to establish reliable TCP fallbacks, thereby disrupting DNSSEC validation. Fragility in Ephemeral/Containerized Resolvers: These types of resolvers are commonly found on exit nodes and are unable to persist the newly established trust anchor, resulting in a SERVFAIL response for valid domain names. Hardcoded Fallback Behavior: Systems default to pre-compiled public resolvers, such as those provided by Android, Chrome, and systemd-resolved, which typically point to 8.8.8.8 (Google Public DNS). DDR/DNR Reinforcement: Encrypted-DNS discovery directs clients to the same designated resolvers—predominantly dns.google. Once this failure is resolved, the change becomes permanent. Market Capture Dynamics: DNS traffic will increasingly shift to hyperscaler infrastructure. Google Public DNS is poised to capture the largest share due to its widespread integration across Android, Chrome, and various client platforms. Governance Context: This technical break occurs under documented ICANN leadership overlaps with Google. Notably, ICANN President & CEO Kurtis Lindqvist has publicly described the October 2026 rollover as “routine,” despite the inherent risks involved. Former Google Cloud Security CTO Ryan Hurst, who was instrumental in architecting Google Trust Services, was appointed as the Backup Trusted Community Representative during the actual KSK cryptographic ceremony. Additional liaison roles and board-level connections further reinforce governance structures that favor the primary beneficiaries of the resulting traffic shift. These structural alignments do not require proof of intent; they establish the conditions under which the break mechanism leads to durable centralization. Impact on Tor Exit Nodes: Exit nodes utilizing affected resolvers will experience SERVFAIL responses for DNSSEC-signed clearnet domains. Client-side fallback mechanisms will bypass the exit node entirely, redirecting resolution outside the Tor network. This results in degraded reachability, inconsistent performance, and a significant erosion of the decentralized model that Tor is designed to uphold. Operator Actions (Required Prior to October 2026): Verify TCP fallback capabilities and EDNS(0) support (conduct thorough testing with large DNSSEC responses). Audit and enforce trust-anchor updates, including unbound-anchor management. Disable or closely monitor client-side fallback behavior on your relays. Test resolution paths during the dual-signing window. Where feasible, consider directing DoT/DoH traffic to non-hyperscaler resolvers. The “Privacy Web” cannot sustain another centralized chokepoint. Proactive preparation now is essential to ensure that post-rollover migration can be reversed if necessary. Sincerely, JMHBM Forensic Governance Analyst

1 0

Hetzner abuse reports
by Christian Kujau 20 Mar '26

20 Mar '26

Greetings, I'm running a Tor relay (0.4.8.21 on FreeBSD) on a small VM hosted by Hetzner and received an abuse report from them. Although this kinda looks like the topic "Hetzner Netscan False Positives" that was discussed recently[0], I have not found out who initiated the report to Hetzner and I'm also puzzled by the distinct destination addresses. And I also thought it might be good to report this publicly that these reports are still an issue for relay operators. The report is bascially: ------------------- We have indications that an attack has been conducted from your server. Netscan detected from host <my-ip-address> TIME (UTC) SRC SRC-PORT -> DST DST-PORT SIZE PROT -------------------------------------------------------------------- 2026-02-28 11:14:23 xxx 48905 -> xxx.xx.116.12 443 74 TCP 2026-02-28 11:14:24 xxx 48905 -> xxx.xx.116.13 9004 74 TCP 2026-02-28 11:14:12 xxx 23292 -> xxx.xx.116.32 9002 74 TCP [...] ------------------- In the attached report I can find ~500 entries, spanning across 5 minutes, with my address as "source" and several desination addresses that can be grouped into three entities: * 5 entries for UDP traffic to the Xerox Corporation, at least according to whois. Weird, but then again: UDP, spoofable, and I did not consider these 5 entries relevant enough to investigate further. * 5 entries for UDP traffic to 198.18.0.1 -- which is a bogon address, used for RFC 2544 and should not be routed anyway. Weird, that this would show up in their abuse report. * The remaining entries point to network addresses in a /24 network. whois points to a RIPE assignment, and querying RIPE directly for these addresses, they are all marked as "TOR EXIT". So, clearly these addresses are part of the Tor network and I fail to understand who contacted Hetzner, complaining that my relay node contacted...other Tor nodes? Or is it a bad actor, disguising as a "TOR EXIT" and then sending abuse reports to the hosting companies? Does anyone have an idea what to make of this report? Thanks, Christian. [0] https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torp… -- BOFH excuse #217: The MGs ran out of gas.

3 6

Save the date - Updates about Relay Operator Meetup in France
by Jolie Fleure 19 Mar '26

19 Mar '26

[English version below] Salut à toutes et tous, Un "tor relay operator meetup" aura lieu à l'Antenne, Severac, France (47.541451, -2.091871) le samedi 4 Juillet à 16h (l'heure du goûter). Ce meetup est organisé au sein de Camp Interhack [1], des rencontres sur 4 jours de hackerspaces francophones. On prévoit de commencer le meetup par des petites présentations de projets et nouvelles autour du réseau Tor. Si vous savez déjà que vous aurez quelque chose à présenter, faites nous signe en répondant à ce mail (joliefleure(a)riseup.net) Ça nous permettra d'avoir une vague idée du nombre de sujets qui seront abordés. On aimerait que cette première partie dure environ 1h pour garder du temps pour la seconde partie : un temps de discussion plus informel autour d'un goûter. Le Camp a une jauge, mais si vous ne venez que pour le meetup, ou pour moins d'un jour, pas besoin de vous inscrire. Enfin, si vous voulez donner une présentation plus longue et/ou à destination d'un public plus large que les seuls opérateurs de relais, n'hésitez pas à ajouter une contribution au programme du Camp [1] ! On espère vous voir en Juillet ! \(★ω★)/ [1] https://2026.camp.interhacker.space/guide.html --- Dear relay operators, As was mentioned earlier on this list, a tor relay operator meetup will be held at l'Antenne, Severac, France (47.541451, -2.091871), on Saturday 4th of July, at 4pm. This meetup will take place during the "Interhack Camp" [1], a 4-days gathering of the French hackerspace community. Note that the Interhack Camp and the relay meetup will be mostly french-speaking ! The meetup will start with small presentations of tor-related projects / news. If you already know you are coming and want to talk about something, please let us know (joliefleure(a)riseup.net) so that we can have a rough idea of the number of topics. We would like to keep the total presentation part to about 1h. The talks will be followed by another hour (or more!) of informal discussions around drinks and snacks. There is no need to register for the event if you only attend the Tor meetup or stay for less than a full day. If you would like to give a longer talk on Tor and/or targetted at a broader audience than relay operators, feel free to add it to the Interhack Camp program [1]! We hope to see you in July ! \(★ω★)/ [1] https://2026.camp.interhacker.space/guide.html Following previous message / Ce message fait suite à : https://forum.torproject.org/t/tor-relays-re-relay-operators-meetup-in-fran…

1 0

Relay fingerprint transfer
by Keifer Bly 18 Mar '26

18 Mar '26

Hey, So for the relay with the fingerprint 79E3B585803DE805CCBC00C1EF36B1E74372861D <https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36…> OVH deleted the vps due to an error. I will need to start a new relay, but is it possible to configure with the original fingerprint as I have it written here? Thanks. --Keifer

8 10