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

Tor Node infected with ransomware
by skankhunt42 15 Feb '26

15 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

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

07 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

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

06 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

upcoming CIISS update
by nusenu 02 Feb '26

02 Feb '26

Hi, I'm working on a new contactinfo information sharing specification version. Current version (2): https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ Some likely changes will be: * add happy family proof https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/407/diffs * add signal username field https://support.signal.org/hc/en-us/articles/6712070553754-Phone-Number-Pri… * maybe add keyoxide field as suggested by boldsuck: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/iss… Feel free to send me your suggestions and opinions before 2025-06-30 by creating github issues or by replying to this thread. kind regards, nusenu -- https://nusenu.github.io

3 5

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

29 Jan '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!*

4 10

Upcoming Stabilization of Tor 0.4.9.x
by Alexander Hansen Færøy 29 Jan '26

29 Jan '26

Hello Tor Relay Operators! The Network Team, particularly David Goulet, is preparing to mark the Tor 0.4.9.x series stable. It will likely happen in the next few weeks, assuming that we don't run into trouble with the the 0.4.9.4-rc release that comes out this week (along with a probably-final update to 0.4.8). We hope you folks will update quickly, and provide the feedback we need, as you always do. Once Tor 0.4.9.x is released as stable, and is available in your package management system, we urge the relay operator community to begin this transition, particularly by adopting the Happy Family system included in this release. For more information, please check out the documentation[2]. At first, we will need you to co-maintain both the existing `MyFamily` system and Happy Families in parallel. If the network upgrade goes quickly, we hope to deprecate the `MyFamily` system sooner rather than later. This period, when both family systems coexist, will be painful, particularly for our Apple iOS users, due to the memory limitations of their Network Extension API. Once we can get rid of the `MyFamily` system, we expect our directory traffic and memory utilization to drop, which will hopefully make Tor more usable for these users and other users on lower-memory systems. In addition to the memory and traffic issues, we also want to acknowledge the pain points raised by the large operators, who currently need to partition their `MyFamily` settings into multiple logical subsets to avoid exceeding the max descriptor sizes we have in place to mitigate DoS. To use Happy Families, operators using `ansible-relayor`[1] should already have Happy Family key management support in the upstream project's GitHub repository. For everybody else, please have a look at the documentation[2] for more information on configuring Happy Families for your relays. Feel free to reach out here for assistance. Relay operators running a single relay where they currently don't set the `MyFamily` setting won't have to worry about Happy Families at all. Later this year, the Network Team + Network Health Team will have a blog post out on the current status of the Arti Relay project and how we foresee the remaining lifetime of C Tor. Happy Families was a bit of a special feature, as there was an urgent need for it, but it also lets us ignore the `MyFamily` system when building Arti Relay. Thanks! And I hope to see some of you at the Relay Operator Meetup[3] at FOSDEM in the upcoming weekend! Cheers, Alex [1]: https://github.com/nusenu/ansible-relayor [2]: https://community.torproject.org/relay/setup/post-install/family-ids/ [3]: https://fosdem.org/2026/schedule/event/DRMMAB-tor_relay_operator_meetup/ -- Alexander Hansen Færøy

1 0

Turkmenistan Censorship
by Dan 27 Jan '26

27 Jan '26

Hello, I have been emailing with a user of my bridge who is located in Turkmenistan. They contacted me to say that their ISP has blocked my bridge(s) and to request I rotate either the domain name, IP address, or both. Has anyone else found a solution seems to work in this scenario? I'm happy to request a new public IP from my VPS provider but I'd like to avoid purchasing new domain names every few months. Maybe the best option is to buy a cheap domain and setup a "private" bridge that isn't distributed except manually? This bridge is using Webtunnel which the user says is usually harder for their ISP to detect. Should I switch to Lyrebird? Thanks

4 8

Exit-Relay got no flags anymore - appears offline
by cembranutboys 23 Jan '26

23 Jan '26

Dear Tor team, My exit node has not had any flags for a few days. When I start the Tor service, the self-check says it can successfully reach my ORPort via IPv4 and IPv6. I was able to reach all authority servers via traceroute. I don't have a firewall active. I have restarted the Tor service several times, but unfortunately I am still not getting any flags. The node had been running successfully for over 220 days, which is why I don't quite understand the problems now. Fingerprint: F5EFEC7C4C4E4F48393D8EBA8CE18A4D1D3B2F67 Can you please help me? Thank you in advance. CembraNut~

2 2

name resolution with libc
by Marco Moock 22 Jan '26

22 Jan '26

Hello! I operate an exit relay on FreeBSD. I changed the values in resolv.conf (that file lists the actual nameservers, not a local resolver), but tor DNS traffic was still sent to the old servers for days until I restarted tor. How is that handled in tor? -- Gruß Marco Send unsolicited bulk mail to 1768731494muell(a)stinkedores.dorfdsl.de

3 3

Re: name resolution with libc
by Marco Moock 19 Jan '26

19 Jan '26

On 19.01.2026 01:52 D.O. Bronk wrote: > I just tried it out and funny thing, tor also didn't use the new > resolvers. So is my assumption right, that it doesn't use the libc functions, as in that case, the OS should handle that?

1 0