- tor-relays - lists.torproject.org

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

Relays on NixOS
by Clara Engler 14 Mar '26

14 Mar '26

Hey, I wanted to ask whether there any relay operators that also run relays on NixOS. What is your setup? Do you use the package/module from nixpkgs? How do you run multiple relays? Do you override the nixpkgs? ... I am currently thinking on collecting some resources regarding that, any feedback/knowledge here would be very appreciated. :-) Thank You Cλara

4 3

relayor v26.0.0 is released: Happy Family design deployed by default
by nusenu 07 Mar '26

07 Mar '26

Hi, relayor v26.0.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v26.0.0 relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes in this release: * enable Happy Family by default (remove variable `tor_happy_family`) * MyFamily support remains enabled by default as well but will be removed in future relayor releases * drop support for tor version 0.4.8.x and require tor version 0.4.9.x or newer Ensure to upgrade your tor version to 0.4.9.x on your relays and control machine before running this relayor version for the first time. tor version 0.4.9.x packages are available for all relayor supported operating systems (Debian, Ubuntu, FreeBSD). kind regards, nusenu -- https://nusenu.github.io

1 0

Relay operators meetup in France
by Jolie Fleure 04 Mar '26

04 Mar '26

Dear relay operators, Interhack, a network of french-speaking hackerspaces organises a gathering from 2 to 5 July, in Sévérac (Loire Atlantique) in France https://2026.camp.interhacker.space/ Tor-related discussions typically occur at Interhack/hackerspaces events. Following the call for more distributed relay operator meetups, we are thinking of taking the opportunity of this event to propose one there. That would be a rather small meeting, considering the limited size of the event itself and the quite remote location. Also we are very small scale relay operators (currently we operate one relay and a bunch of bridges). Nontheless, we would be very happy to meet other relay operators and push more tor discussions in our hackerspaces. What do you think of this? Is there a more official way of announcing a relay operator meetup than sending email on this list? Are there guidelines for how such meetings should/could be conducted?

2 1

Advisory: Unauthenticated remote trigger of Hetzner's "Netscan" detection
by invisibleprefixes＠mailbox.org 01 Mar '26

01 Mar '26

CVSS v4.0 Score: 6 / Medium CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Hetzner aims to detect portscans from within their network to targets outside their network, especially to destinations not visible via BGP. When their outbound scan detection triggers on a given customer IP address the customer gets an email: "Netscan detected from host ..." If the customer does not react in time, the customer's source IP is blocked from any further communication until the customer responds to the report. According to Hetzner the blocking is enforced after "manual verification" only. Vulnerability Description ========================= An unauthenticated remote attacker, who is able to trigger outbound packets from a given Hetzner customer source IP, can trigger the described portscan detection and block a Hetzner customer's Internet access if the customer does not respond to Hetzner in time. There are many services that allow the provocation of outbound packets by design, a few popular examples: * SMTP: various outbound checks performed for incoming emails (SPF, DKIM, DMARC, ...). The attacker can influence the target of outbound destinations by sending emails from domains under their control. * DNS: Recursive resolver are usually not directly exposed to the public but other servers (SMTP, Webserver, ...) might use resolvers located within the Hetzner network. * Web Applikations can have features that allow users to trigger outbound connections to arbitrary destinations. Examples: * Link previews generated server side (for example on a fediverse server) * Server-Side RSS Readers * Server-Side Request Forgery (SSRF) weaknesses * tor relays It is NOT possible to exploit this without a service on the target system by using source IP spoofing with source IPs from prefixes not announced via BGP. Impact An unauthenticated remote attacker can - in the worst-case - block a Hetzner customer's server Internet access and take all services offline (denial of service) until the block is removed. If a host has multiple source IP addresses only the actually used source IP address is blocked. The integrity and confidentiality of the system is NOT affected. Timeline ======== * 2026-01-04: Advisory is sent to security(a)hetzner.com - including the intended release date of the advisory (2026-02-05). * 2026-01-13: Asked Hetzner for an update via email * 2026-01-27: Sent Advisory to bsi.bund.de * 2026-01-28: Hetzner answered: According to Hetzner it is a customer responsibility to deal with this. * 2026-01-28: We asked Hetzner to clarify how their customers should mitigate this risk if it is their responsibility (no answer). * 2026-02-06: Reply from Hetzner stating that this can not be exploited via source IP spoofing - which we did not claim. * 2026-02-06: We offer a call to clarify the issue * 2026-02-06: Hetzner reply: they will get back to us on 2026-02-10 * 2026-02-06: Advisory publication is postponed due to ongoing emails. * 2026-02-10: Clarify that no source IP address spoofing is involved. * 2026-02-12: Asked Hetzner if they have any further questions and if they have any feedback on the advisory release date (no answer). * 2026-03-01: Advisory is released. Credits ======== We did not discover this and we do not take any credits for the discovery of this issue. This issue got discovered because the Netscan detection also got triggered during BGP outages where some IP prefixes were no longer visible via BGP. Some Hetzner customers were affected by these BGP outages causing Netscan detections.

1 0

No. of connections according to nyx
by tor＠busybear.se 01 Mar '26

01 Mar '26

Hello! I would like to know what is considered a normal amount of connections and what affects that? My exit 7BE9E2EF2BB41BB662D9A3CD68289B9E3DBF8A08 WYSWYG hovers around 4500 inbound, 4200 outbound and sometimes a few directory connections, according to nyx. Output in Mb varies, but increases with the normal lifespan of relays. Is this important, will this increase over time, thus generate more traffic, or does it matter? From what I remember, this have been roughly the same during the lifetime of this relay, no matter what connection speed (5Mb - 1Gb) or which machine I've been running. No restrictions in torrc, as far as I know; Nickname WYSWYG Contactinfo <tor AT busybear DOT se> ExitRelay 1 IPv6Exit 1 Log notice file /home/*/torlog SafeLogging 1 ProtocolWarnings 1 RunAsDaemon 1 ControlPort 9051 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /home/*/Downloads/control_auth_cookie ConnDirectionStatistics 1 ExtraInfoStatistics 1 DirPort 65534 ORPort 65535 NumCPUs 6 Any comments or suggestions are welcome! Cheers! //Bamse

1 0

Hibernate vs 10 Mbps throttle when bandwidth cap exceeded
by forest-relay-contact＠cryptolab.net 01 Mar '26

01 Mar '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Many server providers have a monthly bandwidth limit. It's easy enough to deal with that by using the AccountingMax option so that Tor will hibernate when it reaches the bandwidth cap to avoid service suspension. I run a relay on a provider that, rather than suspending the service, simply throttles the bandwidth to 10 Mbps until the next month when the 8 TB/month traffic cap is reset. I run through that traffic in just half a month, so the relay is only operational 50% of the time. But 10 Mbps is not nothing. What should I do here? I can think of a few options: 1. Set AccountingMax and let the relay hibernate like normal, ensuring that, whenever it is on, it can achieve maximum performance. The "free" 10 Mbps bandwidth can then be used for other things, such as I2P which does not have a ramp-up period. 2. Keep the relay running, relaying up to 1.5 TB/month extra for free, but with the caveat that the relay suddenly becomes overloaded each time it reaches the 8 TB mark until the consensus weight falls. 3. Shortly before the bandwidth cap is exceeded, automatically adjust the torrc to include "MaxAdvertisedBandwidth 10 Mbits", and remove it when the bandwidth cap resets. What is a reasonable thing to do here? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaY/3wQAKCRAw+TRLM+X4 xtgQAQC2HWAGe7tcmuOGu2v/473IQC9lWHL03lUUpuJPSpGZpwD+LItXaqzV4vPy phr/rC4LNDZ1AY8m2ZuTzd4MwsVpsgI= =c+pq -----END PGP SIGNATURE-----

3 3