- tor-relays - lists.torproject.org

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

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

02 Mar '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

3 3

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

big german provider "Deutsche Telekom" has started blocking access to their SIP servers
by iji＠gmx.net 28 Feb '26

28 Feb '26

Hi a big German provider "Deutsche Telekom" has started blocking access (at TCP layer) to their SIP servers in February 2026. That means running a middle tor on this provider line results in a non-functional provider SIP service. You have to choose between running a middle tor or a working provider SIP service.

9 19

Happy Families migration status dashboard
by Tor at 1AEO 24 Feb '26

24 Feb '26

To help answer “what still needs to happen before the network can rely on Happy Families (and eventually stop depending on MyFamily)?”, we put together a small public dashboard that tracks the main rollout gates: https://metrics.1aeo.com/network-health.html#happy-families High-level flow: 1) Voting directory authorities upgrade (v0.4.9.x+) DAs need to be on v0.4.9.x+ so the network can move forward with the newer directory protocol pieces. 2) Consensus method moves to 35 Once a >2/3 voting DA majority supports method 35 (7/9), the consensus can adopt it. 3) Relays publish Happy Families material Relay families configure FamilyId so relays publish family-cert, which lets directory documents/micro descriptors carry the happy families identifier information. 4) Clients upgrade and use it As Tor clients (Tor Browser, tor, etc.) widely consume happy families identifiers, then deprecating MyFamily becomes possible. The dashboard shows live counts for DA readiness (v0.4.9.x+ and method-35 support), current consensus method, relay publication (family-cert), and a few “how much of the network is ready” slices (guards/exits/CW/bandwidth). References: - Relay operator guide (FamilyId / Happy Families setup): https://community.torproject.org/relay/setup/post-install/family-ids/ - Proposal 321: https://spec.torproject.org/proposals/321-happy-families.html Feedback welcome—especially if there are other readiness signals you’d like to track, or if you spot anything that looks off for your relays. On Tuesday, February 3rd, 2026 at 5:00 AM, Alexander Hansen Færøy via tor-relays <tor-relays(a)lists.torproject.org> wrote: > On 02/02/2026 22.36, tor_appliedprivacy.net via tor-relays wrote: > > Today we enabled the happy family setup across all our relays. > > > > Since all our relays run in a single /24 we also removed MyFamily at the > > same time. This should help reduce the overhead introduced by MyFamily. > > This is not what any of us on the Network Team are recommending right now, but > if others think this is a good idea despite that: please ensure that your IPv6 > addresses, at the very least, are also within the same /32 in addition to the > /16 requirement for IPv4. I am almost certain that is always the case, but > please just be sure before you proceed. > > We are very interested in hearing feedback on the 0.4.9.4-rc release candidate > and in resolving any issues before we stabilize 0.4.9. Maybe the above approach > will reveal some issues :-) > > Cheers, > Alex > > -- > Alexander Hansen Færøy > _______________________________________________ > tor-relays mailing list -- tor-relays(a)lists.torproject.org > To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org >

1 0

Question about Tor relay guard/middle probability fluctuations
by Tor-relay 23 Feb '26

23 Feb '26

Hi everyone, I have a question regarding my Tor relay’s lifecycle. Since the beginning, I have noticed that the guard and middle probabilities fluctuate significantly. I have not observed this behavior when comparing with other operators’ relays. After some time, the relay receives the Guard flag and the middle probability decreases, later it loses the Guard flag and the middle probability increases again. I waited for a long time to see whether this would stabilize, but the behavior has remained unchanged. I would like to ask what the possible reasons for this could be, and whether it might be related to my configuration. Relay fingerprint: 8E6E3B11C9AD2E9E3B3FC53A4E43D1AE3BEBE444 Tor metrics link: https://metrics.torproject.org/rs.html#details/8E6E3B11C9AD2E9E3B3FC53A4E43… Thank you in advance. P.S. If you check the relay statistics, please ignore the low consensus weight and probabilities during the last month, that was caused by my own mistake.

3 3

the case for relay state persistency
by Gilberto 23 Feb '26

23 Feb '26

Hello everyone, In our diskless infrastructure [0][1], we store all configurations generated by the node inside the TPM's memory. These memories are very limited (1-9k), but more than sufficient for saving the long-term keys of the relays. However, we have a problem: when rebooting the machines, we lose the state file and, with it, the bandwidth measurements of the various relays. This is quite annoying because upon reboot, our relays all start up announcing 0 B/s, and it takes them days to regain their bandwidth. Unfortunately, these files are too large to be stored in the TPM. We would like to be able to generate the BWHistory configurations based on some arbitrary values that we write into the node configurations, and then let the node handle redoing the measurements upon reboot. However, among all the configurations, it's not clear to us which ones are important for our needs and which others we can leave empty. In general, we would like to open a discussion, in view of Arti, about the organization of the datadir. Currently, it's not very clear which files are important for runtime, which are for persistence, etc. From our point of view, it would be quite useful to be able to group persistent data into just a few files, for example, one for all keys and one for states/configurations. Thank you, g [0]: https://osservatorionessuno.org/blog/2025/05/patela-a-basement-full-of-amne… [1]: https://osservatorionessuno.org/blog/2025/12/patela-v2-from-certificates-to…

4 4

Re: Issues with My Tor Relay
by stay.hydrated834＠passmail.net 22 Feb '26

22 Feb '26

Hi everyone, Thank you for the reply and the information you provided. While preparing my response about the blocked traffic, I wanted to clarify the NAT and WAN rules in the screenshots and replace the aliases with the actual IP addresses. During that process I discovered that I (the numb nut of an administrator) forgot to fill in the NAT alias, so there was never an active NAT rule only the WAN rule was present. Because both the NAT and WAN rules are now active, the Tor relay is functioning correctly: no traffic to port 9001 is being blocked, and outbound traffic is unrestricted. I wonder why some connections were allowed by the WAN rule while others were denied and are now only allowed due to the NAT rule. Bandwidth: Average throughput: ~60 Mbps (occasionally up to 140 Mbps) Recent spikes: short bursts up to 420 Mbps training i guess? Due to frequent firewall restarts while I’m re‑configuring my network. I expect the traffic to stabilize as the network settles and after the training finished, and I’m happy if the relay can make use of any unused capacity. 1000Mbps would be the Maximum so there is alot of room to grow. :D Unexpected traffic bursts Every few hours I see dozens of Tor nodes connecting to my relay for 2–5 minutes, resulting in 1,000–7,500 connections dropping. These bursts don’t line up with the bandwidth spikes as far as i seen. My CPU usage, which is usually around 1 %, can rise to about 1.2 % during those periods. Im glad i already thought its static. :D I don’t think this is an attack—nothing I’ve seen, even a smart bulb, generates comparable traffic. I’m wondering if I still have a misconfiguration somewhere. Regarding Snowflakes Is it possible to Route all of my phones (apps) traffic still through WireGuard back to home while allowing Orbot to use the mobile network to open a Snowflake relay (my IP changes every 24 hours after a phone reboot). I have an unlimited 25Mbit not fast but steady. Im on GrapheneOS Screenshots I’ve attached screenshots that highlight exactly what is being blocked, so you can see the traffic patterns I described. Thanks again to everyone who runs relays; your experience helped me finally get mine working. <3 Stay hydrated! Cheers

1 0

Scheduled migration: Nothing to hide infrastructure (23-02-2026)
by Nothing to hide 20 Feb '26

20 Feb '26

Hi everyone, This is a heads-up that a significant portion of the Nothing to hide infrastructure will be undergoing a major upgrade and migration on Monday 23 February 2026. We are replacing older servers and networking equipment with modern high-performance hardware and moving to a new data center. What to expect: * While we aim to limit downtime to a few minutes, extended outages are possible depending on how the migration proceeds. * In the days following the migration, many of our existing relays will be assigned new IP addresses and/or roles. * Once we consider the new network and infrastructure stable, we will be adding more relays to the network. This move also provides much-needed headroom for auxiliary services we plan to offer Tor operators, such as DoT, DoH, DoQ, and NTS. We'll share more details on these in the near future. Best regards, Nothing to hide

1 0

Programmatically determine if a relay is hibernating
by forest-relay-contact＠cryptolab.net 18 Feb '26

18 Feb '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. What is the authoritative way to determine if a relay is hibernating? I would have thought that using the control socket would be best, but Tor seems to unlink it when it enters hibernation, so Stem does not work. There's a possible heuristic by checking if /run/tor/tor.pid exists when /run/tor/control does not, but that's fragile because it assumes that the control socket is even enabled. Parsing the logs is doable, but also quite fragile. And I could certainly parse /var/lib/tor/state, but its format is surely subject to change at any time. How do I correctly determine whether a Tor process is in hibernation? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaZERAgAKCRAw+TRLM+X4 xshIAQCjNVgq0vBzT+MJhbn8Vetj3UObU8DinVvp3gtj9DeLKgD/aKy7N3nvCUSu zFSSFZTCR0MFxQh9TxjmYO/tKRrPoAE= =gAnQ -----END PGP SIGNATURE-----

3 3

handle malicous IPv6 systems abusing the /64 hostmask
by Toralf Förster 15 Feb '26

15 Feb '26

I extended my DDoS solution [1] by blocking systems where malicous connections attempts where observed from up to 256 IPv6 addresses of the same /64 block within 24 hours from hosters providing /64 hostmasks. For now it is rather a quirk than a generic solution. But it works well. And it extends the solution to accept now manual block requests like ipset add tor-ddos6-5443 <IPv6 address> -exist [1] https://github.com/toralf/torutils?tab=readme-ov-file#details -- Toralf

2 2

Tor Node infected with ransomware
by skankhunt42 14 Feb '26

14 Feb '26

Hello there, today I woke up to an execution error of the relayor playbook. I then tried to look into the affected node (tor-nl1.skankhunt42.pw; nickname skankhunt42nl1) and couldn't SSH into it. So I went to the hosters VNC console and found a ransomware notice: Your files are encrypted, requires payment for decrypting Contact us: Telegram: @cloudcone_raidbot UUID: bfaa20d9-7b11-417d-a702-cfa95d6c203c I then tried to boot into recovery and look at the disk but as expected, partition table and ext4 superblocks were gone. hexdump head of the disk was just the ransomware note shown above. I was running Ubuntu 24.04 Minimal with ESM enabled and unattended-upgrades, everything else managed by relayor. I obviously checked the other nodes for unsual SSH logins (as they had the same SSH key) and didn't found anything. I am rotating the keys for now and shut down the VPS at HostSlick. Not sure if there is something to further investigate maybe. What's odd is that I couldn't find anything about "cloudcone_raidbot", doesn't even exist on telegram. I really want to understand what I did wrong. Maybe someone with more experience may take a look at it? Best, skankhunt42

4 4

Issues with My Tor Relay
by stay.hydrated834＠passmail.net 13 Feb '26

13 Feb '26

Hello there, For the past week I’ve been running a Tor relay using the Tor‑Relay plugin on my OpenSense. While the relay appears to be functioning, I’ve noticed a few irregularities: 1. Selective blocking: Some IP addresses that connect to me are being denied by default, whereas others with similar characteristics connect without any issue. 2. Low bandwidth usage: The relay isn’t consuming much bandwidth. I’m not sure whether this is normal while the relay is still learning its capacity or if something else is limiting traffic. 3. No connections on port 9030: So far, I haven’t seen any inbound connections to the directory port (9030). For testing, the following IP is reachable via ICMP ;) - 109.199.164.117 – Port 9001 (OR) / DIR 9030 Could you advise on why these behaviors are occurring and whether any configuration changes are needed? Thanks for your help, and stay hydrated!

3 2

Call for more Snowflake proxies!
by gus 07 Feb '26

07 Feb '26

Dear relay operators, The Snowflake network is currently overloaded and we need more Snowflake proxies. If you have spare bandwidth or available servers, please consider running Snowflake proxies. As online censorship continues to increase around the world -- particularly with the recent Internet restrictions in Iran[1] --, we are seeing a significant increase on snowflake usage. We urgently need more Snowflake proxies to help handle this surge and ensure that users can continue to access the open Internet. Please share this call with your friends, communities, hackerspaces and anyone who may be able to help! Gus ### How to help There are multiple ways to run snowflake proxies: - Option 1: Run a browser-based proxy. Click the link below, switch it ON and leave the tab open: https://embed-snowflake.torproject.org/ - Option 2: Install Snowflake browser extension: https://snowflake.torproject.org/#addonBtns - Option 3: Run Snowflake standalone proxy (recommended for relay operators): https://community.torproject.org/relay/setup/snowflake/ - Option 4: Install Orbot (iOS/Android) and enable Kindness mode. https://orbot.app/ ### FAQ for relay operators Q: I'm operating a Tor relay, can I run a Snowflake proxy on the same IP? A: It might not be helpful for censored users as Tor relays are frequently blocked on censored regions. Q: I'm operating a Tor bridge, can I run a Snowflake proxy on the same IP? A: It might expose your bridge IP address and censors might take this opportunity to block your bridge. Q: Can I run Snowflake proxy for a short period? A: Yes. Proxies can run for any amount of time. Even short periods help increase available capacity. Q: Do I need to share my Snowflake proxy manually? A: No. Your proxy is automatically distributed by the Snowflake broker. After setup, no further action is required. Q: Where can I see Snowflake proxy statistics? A: Snowflake proxy statistics are available from Tor Collector. You can download the data here: https://collector.torproject.org/recent/snowflakes/ [1] Censorship analysis in Iran: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… -- The Tor Project Community Team Lead

2 2

Hetzner Netscan False Positives
by tor_appliedprivacy.net 06 Feb '26

06 Feb '26

Hi, we just wanted to let you know that we got a Hetzner network contact yesterday here at 39C3 to try to get this issue solved at the root. We can not promise anything at this point but we will likely update this thread in a few weeks (January) about the status with Hetzner on this topic. best regards, tor(a)appliedprivacy.net

6 9

Re: Question about Snowflake proxy on non-exit tor relay
by gus 06 Feb '26

06 Feb '26

Hi, Yes, it applies to all relays, independent of their flags (exit, guard, middle.). Thank you! Gus On Fri, Feb 06, 2026 at 10:58:43AM +0100, Tor-relay wrote: > Hi, > > I have a question regarding the following FAQ entry: > > “Q: I'm operating a Tor relay, can I run a Snowflake proxy on the same IP? > A: It might not be helpful for censored users as Tor relays are frequently > blocked in censored regions.” > > Does this limitation also apply to non-exit relays, or is it mainly a > concern for exit relays? > > Thanks in advance. > > > On Thu, Feb 5, 2026, 17:34 gus via tor-relays < > tor-relays(a)lists.torproject.org> wrote: > > > Dear relay operators, > > > > The Snowflake network is currently overloaded and we need more Snowflake > > proxies. > > > > If you have spare bandwidth or available servers, please consider > > running Snowflake proxies. > > > > As online censorship continues to increase around the world -- > > particularly with the recent Internet restrictions in Iran[1] --, we are > > seeing a significant increase on snowflake usage. We urgently need more > > Snowflake proxies to help handle this surge and ensure that users can > > continue to access the open Internet. > > > > Please share this call with your friends, communities, hackerspaces and > > anyone who may be able to help! > > > > Gus > > > > ### How to help > > > > There are multiple ways to run snowflake proxies: > > > > - Option 1: Run a browser-based proxy. Click the link below, switch it > > ON and leave the tab open: https://embed-snowflake.torproject.org/ > > > > - Option 2: Install Snowflake browser extension: > > https://snowflake.torproject.org/#addonBtns > > > > - Option 3: Run Snowflake standalone proxy (recommended for relay > > operators): > > https://community.torproject.org/relay/setup/snowflake/ > > > > - Option 4: Install Orbot (iOS/Android) and enable Kindness mode. > > https://orbot.app/ > > > > ### FAQ for relay operators > > > > Q: I'm operating a Tor relay, can I run a Snowflake proxy on the same IP? > > A: It might not be helpful for censored users as Tor relays are > > frequently blocked on censored regions. > > > > Q: I'm operating a Tor bridge, can I run a Snowflake proxy on the same IP? > > A: It might expose your bridge IP address and censors might take this > > opportunity to block your bridge. > > > > Q: Can I run Snowflake proxy for a short period? > > A: Yes. Proxies can run for any amount of time. Even short periods help > > increase available capacity. > > > > Q: Do I need to share my Snowflake proxy manually? > > A: No. Your proxy is automatically distributed by the Snowflake broker. > > After setup, no further action is required. > > > > Q: Where can I see Snowflake proxy statistics? > > A: Snowflake proxy statistics are available from Tor Collector. You can > > download the data here: > > https://collector.torproject.org/recent/snowflakes/ > > > > [1] Censorship analysis in Iran: > > https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… > > -- > > The Tor Project > > Community Team Lead > > _______________________________________________ > > tor-relays mailing list -- tor-relays(a)lists.torproject.org > > To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org > > -- The Tor Project Community Team Lead

1 0

Tor Relay Operator Meetup at FOSDEM 2026
by Alexander Hansen Færøy 05 Feb '26

05 Feb '26

Hello Tor Relay Operators, We will not only have a booth at FOSDEM this year, but we will also have a Relay Operator Meetup. The event will take place as a BOF on the Sunday (2026-02-01) at 13:00 to 14:00 in room H.3244. I'll do a little intro when we arrive, but I'll make sure we have enough time for a long Q&A session. Remember, this is an excellent opportunity to show up, ask questions, perhaps answer some questions, and say hi to some of your fellow Tor operators. For more information, please check out: https://fosdem.org/2026/schedule/event/DRMMAB-tor_relay_operator_meetup/ See you there! Cheers, Alex -- Alexander Hansen Færøy

2 4

appliedprivacy.net relays moved to the happy family setup
by tor_appliedprivacy.net 03 Feb '26

03 Feb '26

Today we enabled the happy family setup across all our relays. Since all our relays run in a single /24 we also removed MyFamily at the same time. This should help reduce the overhead introduced by MyFamily.

2 1