- tor-relays - lists.torproject.org

Re: Tor Node infected with ransomware
by skankhunt42 03 Feb '26

03 Feb '26

Hi, Thank you for the replies. At the time of writing I was in total panic mode and rotated all my keys. Only after that I saw all these posts from users across different hosters facing the same issue. It was a good practice to just re-evaluate my OPSEC, though. I opened a support ticket with my hoster (HostSlick) and got a reply about 12 hours later. I didn't want to re-deploy until they gave confirmation they are clean again. Luckily, with the awesome relayor playbook I recovered the relay, I just lost the Guard flags, but I think thats fine for now, they'll come back :) However, I decided to turn my back on that hoster and cancelled my VPS, will be up for a few more months. We already had a few disagreements when the problem with spoofed IP abuse reports arose last year. My relay was suspended (without any notice) at the time for multiple days and it took some time to explain to the hoster that the packets did not came from me. PS: Thanks Marco, I will look into a centralized solution for collecting logs, just to make any future incidents easier to understand. Best, skankhunt42

1 0

upcoming CIISS update
by nusenu 01 Feb '26

01 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 28 Jan '26

28 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 28 Jan '26

28 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 22 Jan '26

22 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 21 Jan '26

21 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

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

18 Jan '26

Am 18.01.2026 um 14:19:28 Uhr schrieb D.O. Bronk: > One of my exits is on FreeBSD too, I didn't know this yet, so good to > know. But normally a 'reload' instead of a 'restart' will suffice. > This way your tor relay doesn't lose it's uptime etcetera. > > If I'm not mistaken, this should also be done after sysctl fine > tuning. Is that anywhere documented? -- Gruß Marco Send unsolicited bulk mail to 1768742368muell(a)cartoonies.org

1 0

Tor guard relay memory: what actually reduces RSS on Ubuntu 24.04
by Tor at 1AEO 17 Jan '26

17 Jan '26

Hello, We ran experiments over 10 days on ~100 Tor guard relays (Tor 0.4.8.x) on Ubuntu 24.04 to determine which memory optimizations materially affect long-term, steady-state RSS under sustained load. Results: allocator choice dominates steady-state RSS outcomes. Using mimalloc 2.x and jemalloc 5.x produced large, sustained reductions in resident memory, on the order of 70–80 percent, compared to the default glibc malloc; tcmalloc showed a smaller but measurable improvement. By contrast, the two commonly cited configuration parameters, MaxMemInQueues and MaxConsensusAgeForDiffs, showed little to no impact on steady-state RSS when adjusted in isolation. Operationally, these reductions allow higher relay density per host, with guard relay memory footprints decreasing from roughly 5–6 GB to approximately 1–2 GB per relay under sustained load. Attached are the summary chart and table. Full methodology, comparisons, and data are here, with links to scripts on GitHub to reproduce: https://www.1aeo.com/blog/tor-memory-optizations-what-actually-works.html Tor at 1AEO Approach Result Viable? mimalloc 2.1.2 1.16 GB (80% reduction) Yes jemalloc 5.3.0 1.59 GB (72% reduction) Yes tcmalloc 2.15 3.79 GB (33% reduction) Partial mimalloc 3.0.1 4.39 GB (23% reduction) Partial DirCache 0 0.29 GB (94% reduction) No (loses Guard) MaxMemInQueues ~5.0 GB (no change) No MaxConsensusAgeForDiffs ~5.7 GB (no change) No Periodic restarts 5.0–5.3 GB (minimal) Workaround only glibc 2.39 (control) 5.68 GB Baseline

3 5

forest08 dropped out of the consensus; all authorities think it is down
by forest-relay-contact＠cryptolab.net 15 Jan '26

15 Jan '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. My relay with fingerprint BDB0F71C8EB2572080D38F036E3EB33494500E9E is no longer being recognized by the consensus. I can confirm that the entire subnet it is on is able to reach the directory authority's ORPorts, but, according to the consensus health page, not a single DA reports it as running. This has lasted for 11 hours so far. How do I get it back in the consensus? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaWjfzAAKCRAw+TRLM+X4 xsIVAP9E6Ijjzt1yt7AtFTUy6TSoTnVjGMgP2A09bZr0TWNseQD/SqWS27zFl2zq wdEZyZfQHArlgB4YHyS7j06gij2GzAo= =XdXh -----END PGP SIGNATURE-----

2 2

Tor exit relay lifecycle - update
by Georg Koppen 14 Jan '26

14 Jan '26

Hello! We have been working on a proposal to introduce an exit relay lifecycle (similar to the one we have for non-exit relays)[1]. That proposal got recently accepted and merged[2] and now we need to get it implemented. Folks interested can follow the implementation part by tracking the respective ticket in core/tor[3]. For more context see the discussion in the original exit lifecycle ticket[4] as well. Thanks, Georg [1] https://gitlab.torproject.org/tpo/community/policies/-/issues/32 [2] https://gitlab.torproject.org/tpo/community/policies/-/blob/main/docs/relay… [3] https://gitlab.torproject.org/tpo/core/tor/-/issues/41196 [4] https://gitlab.torproject.org/tpo/network-health/team/-/issues/220

1 0

Tor Relay Operator Meetup at 39c3
by Alexander Hansen Færøy 06 Jan '26

06 Jan '26

Hello folks, Leibi has managed to get a spot for a Tor Relay Operator Meetup here at #39c3. Folks can join us on day 3 at 00:00. For more information, check out: https://events.ccc.de/congress/2025/hub/en/event/detail/tor-relay-operators… Cheers, Alex -- Alexander Hansen Færøy

2 2

Relay forest18 is still not on the consensus
by forest-relay-contact＠cryptolab.net 06 Jan '26

06 Jan '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. One of my new relays is simply not showing up on the consensus. It's been a few days already. I ended up wiping /var/lib/tor and restarting in order to get a new fingerprint, but it has been a while and it is still not showing up on the consensus. I have 21 relays, and this one, the 18th, is the only one having this problem. Even the 21st has shown up on the consensus already. The new fingerprint is 6435C5172690160DA25681BEBA1EA5EAC6F2BE70. Is it possible that it has been incorrectly blacklisted due to being mistaken for one of the relays involved in the recent sybil attack? The IP address is 160.250.225.3. What confuses me is that, even after changing fingerprints, it still is not showing up. It is connected to the network and is reachable from the outside. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmk1NxEACgkQBh18rEKN 1gtojw/9Hoix29gE4oevhlRJvGLftgbJHv5caZ7iGNZ7KdN7R/8HQ//0InfyG5d4 8Mb49D2jzNfLK+89svlMyNso5ZqR3sMcy7dpnTNAq+PlxB84AwQE/9Qb/8R3sTDZ A2S8ezzCtViQTEQh9eYx+zmnjJckwVt4sAbjumc6t3kIdN+f7CjOj2SZ+AbT6e4l hBZdaGwKLUQhPzL35SK20RSTjIvVNDHAwMo5rR6BsHCj/+W+3fmAG29pieqCAGp/ lwXR6E4EMII0f53Pb65ZB38FOTuMkBBFL0I3WUB90IqS4z+L3U9oU2u7KY1np1lp ApCSbQjoY+NSgpdJ0yH5b1ZZEvEnr1OhQqY0RMpVTLXOuByj79NG31mjE1v8aUaN a5Lwk6scYXuPr8ryOkxkX80tN5V21pIQWt9hubpXBHtPLvfGmTS51DwwOOEKYoIA yyFnVST75f38uyvm73H48s9c68263I5fKQvFCzUmq8Go0lpbLutjxC8LNML3J0cq 0rIINHWKDw4UjnboKihkuoRdXi+tH2ERW3ZAoKVUXTi1VHomwfDvBHJSYxb3SipI 54Qjrnd6IFr8LaHcTfFacrD/OH4WAYnGCE3lC4Ly3xX0P8Cb9KDkop8nXPuBJAup Jq7GgDP8vsmWW6hp4q/Sh+ajHkeZm/luNWA3DZqsp4q0grHi/IM= =Zdqz -----END PGP SIGNATURE-----

7 28

Netscan Hetzner
by Diyar Ciftci 04 Jan '26

04 Jan '26

Good evening, Apologies as this is likely the incorrect way to do things. I'm not fantastic with mailing lists. I saw on tor forum that some people were getting these netscan emails from hetzner. https://forum.torproject.org/t/tor-relays-abuse-report-from-relays-in-famil… I got my first a few months ago and I just got my second one about an hour ago. Both times it was to the 1st amendment group IP addresses. Last time I just clicked their check button and it passed and then I gave reasoning in the next link. For some reason it doesn't seem to be liking when I click the first link this time and keeps saying not solved. I don't know what my best course of action is. I've gotten 2 reports for hetzner for a guard and 0 for netcup for an exit relay :( I saw in the forum post (which is to a clone of the mailing list) about temporarily blocking tor but that feels a bit deceptive so I don't really want to go down that route. The best thing though it may be a long process as there may be a potential harm to how circuits are built negatively affecting user anonymity is for the tor program to operate in a manner so that it doesn't look like a netscan to some sensitive providers like hetzner even though we know it isn't a netscan anyways. If this issue keeps coming up with hetzner I may look at not hosting a tor relay with them because I have a lot of stuff on this server like my personal website and project mirrors and such and don't want those to be negatively affected due to a unjust IP ban by hetzner for running a tor relay. Any advice? Kind regards, Diyar Ciftci

6 10

Questions about running an exit relay
by tor＠rehcamp.de 03 Jan '26

03 Jan '26

Hi dear list, I hope I am in the correct place for my questions regarding my tor setup. I am currently running a guard/middle relay on a vServer. The relay runs inside a docker container, exposing OrPort and DirPort externally and ControlPort and MetricsPort internally. On the same machine, but in different docker networks (except for prometheus for metrics), multiple other containers providing my personal infrastructure are running. All of them run behind caddy, which only forwards requests coming to specific subdomains on a specific domain. First of all: Is this already a bad idea? Do you seperate tor relays and personal infrastructure physically or in VMs instead of containers? Now, as netcup is my provider and they seem to tolerate exit nodes, I am thinking about allowing exits. I assume this would increase visibility of my server and maybe attract more attention. Knowing the IP address of the tor node, it could be possible to find other domains pointing to it (the PTR record however points to an irrelevant entry) and maybe find the subdomains leading to (still login-protected) infra. Do you think this is a reason not to open the relay for exits? I only have a single IPv4 address to use, additional addresses would imply additional costs. However, I do have a /64 block of IPv6 addresses. For IPv6, i could separate the tor address from the address used personally and therefore make it impossible to reach anything except tor over the designated address and covert any other domains, as they won't be associated with the tor address. Do you think this would be needed/enough? In this case, I would restrict the relay to IPv6-only exits. I am sorry if I could have found more information in the docs, but everything that I did find did not answer my questions enough. Kind regards.

5 5

CPU requirement gone up?
by gerard＠bulger.co.uk 31 Dec '25

31 Dec '25

(Linux 6.8.0-90-ge...) Tor 0.4.8.21 (recommended) I used spin up Webtunnels on very cheap VPS, bandwidth and uptime being my main consideration. But in recent days CPU is 99% even at quiet sites with under 50 outgoing connections. This is new. It would run at 30-50% before. Gerry

4 5

abuse report from relays in family 7EAAC49A7840D33B62FA276429F3B03C92AA9327
by Dimitris T. 29 Dec '25

29 Dec '25

Hey all, got an abuse report today from Hetzner concerning one middle relay we're running there. allegedly, our relay has been port scanning (port 443 only) some members of https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA27… (just from family relays in 96.9.98.0/24 range, all using ORPort 443) anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp? thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans... best, d.

14 29

Consensus frequently reports relay down, despite relay passing traffic
by forest-relay-contact＠cryptolab.net 29 Dec '25

29 Dec '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. One of my relays, forest19 (E21B4A2C2852298186C0EA7E2F900EF03AE38D69), frequently appears offline in the consensus despite my uptime monitors and bandwidth graphs showing uninterrupted activity. About once a day to once every other day, I get a Tor Weather notice that my relay has been offline for the last 4 hours. The relay is able to ping all authorities but Sarge, and I am not seeing abnormally high packet loss. How do I troubleshoot this? Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlN4PQACgkQBh18rEKN 1gtdxg//QENLNjbb8Ukg40Cyd5vaJDw7PSmcS7XKTh1VID6ZrCdw53arHiYBfvZM Ez26SRD+4gj6//Oz+uz2A0jcBJ8fa+RewTwm4WBthiNGLs8hhyt03CN9zA/j/sm0 9VEkxORYAnjTwJmUQYZKIzfF0GdjJirfuk/daq2q5s4Uxd1tspSSTvYI/O/myE+l 7M5qXtu7OSAJynwYGySQPudt9dGgXdb7fDCATaM7gczXpkHFkSxwIrCNHGYPPL+/ Y/xewRs5rHb0TS8DRJcvDKNBSRaTTNLUQkmiRN4it7pY3w/DWkEWduTwvufMsvK3 3AOs75oaO2cs2WVkqQag12uHTtw78uzegObZl9RPaWmThrbQ8SF/co+10zUUlUa9 UXik2zgpAyQzLLb6TNmLAkNAALQUXvO6YZnZ2z6lrkiXW5ySsgmAhgKaPX9JufKz xbXJ2kkyWRt5xP4y/I5tHj+vmjhLjahmn/gy2O3S1atdTwsd5OX0sn1MzdLfsjw2 9DPaCZpvaOCXwHoQFYM5q0K+JqDNrhsgoCMbjnIhrj/J19OCCYoaLPDd4rxrMOJ8 nsl6hzxi6804hol4A9MDnWzNpAxdxFahSbEE523TfG6OaQG4rw2GyP15Ai6NK6fO Am1cgei2NDAZBquFNB7tI2gfGvle+n7boviHdaMNmlEqMhLL7Pk= =hlTa -----END PGP SIGNATURE-----

4 4

Manual calculation of the bridge-moji
by Marek Küthe 28 Dec '25

28 Dec '25

Hello, When I add a bridge in Tor Browser, the fingerprint is displayed with four emojis. I would be interested to know how I can create this fingerprint manually, for example with Ansible or a Python script. The reason for this is that I would like to list my bridges with their fingerprints on my website, preferably with emojis as well. I would appreciate a reply! Best regards, Marek Küthe -- Marek Küthe m.k(a)mk16.de er/ihm he/him

2 1

RouteFluxMap: open-source Tor relay map with historical bandwidth snapshots
by Tor at 1AEO 26 Dec '25

26 Dec '25

Hello tor-relays, I’m sharing a new open-source visualization tool for exploring Tor relay distribution and bandwidth over time (updated daily): - Live site: https://routefluxmap.1aeo.com - Open-source code: https://github.com/1aeo/routefluxmap What it does: - Interactive world map of Tor relays, with relay presence and density visualized using bandwidth-weighted aggregation - Flow-style visualization based on the probability of traffic per relay, derived from each relay’s advertised bandwidth and consensus weight (not traffic tracing) - Historical snapshots built from Tor Collector / Onionoo data, covering 2007 through present - Country-level summaries showing relay count and aggregate bandwidth Why this is useful for relay operators: - Provides a fast, high-level view of where Tor bandwidth is concentrated geographically - Helps identify broad shifts in relay distribution or bandwidth that may correlate with performance or reachability changes - Useful for gaining network-wide context when debugging issues that aren’t obvious from single-relay metrics alone Implementation notes: - Static frontend built with Astro + React using Deck.gl and MapLibre - Data pipeline aggregates publicly available Tor network metadata into versioned historical snapshots Feedback is welcome, particularly on which additional historical or aggregate views would be most useful for operators. Significant inspiration and guidance from an open source and 7 year previously retired effort, TorFlow: https://github.com/unchartedsoftware/torflow Tor at 1AEO 1st Amendment Encrypted Openness (1AEO)

2 2

(FWD) December 2025 tor-edu update
by Roger Dingledine 26 Dec '25

26 Dec '25

Hi folks! Here is the latest update from the EFF Tor university relay campaign. We've added eight new relay groups since the last update. You can see the campaign page here: https://toruniversity.eff.org/ One of its advocacy goals is to show momentum at getting more relays running in universities and other educational institutions, first because universities make sense from an education/community/research perspective: https://toruniversity.eff.org/administrators/ and also because we want to help show the world that running relays is a normal activity that many groups around the world do, for a variety of reasons. If you are connected to an educational institution and you are reading this and want to get involved, please reach out to us! --Roger ----- Forwarded message from Roger Dingledine <arma(a)torproject.org> ----- Date: Fri, 26 Dec 2025 11:16:21 -0500 From: Roger Dingledine <arma(a)torproject.org> To: toredu-announce(a)lists.eff.org Subject: [Toredu-announce] December 2025 tor-edu update Hello excellent university relay operators, Since the July update, we have added 8 more new relay groups to https://toruniversity.eff.org/: * NYU Abu Dhabi (UAE), run by Zacharia Kornas in Christina Pöpper's research group * University of Macedonia (Greece), run by professor Panagiotis Fouliras * Bern University of Applied Sciences (Switzerland), run by professor Christian Grothoff * Hampden-Sydney College (US), run by professor William Tolley * A second relay at Arizona State University (US), now an exit relay, run by Pratham Gupta connected to professor Yan Shoshitaishvili's group * Fort Hays State University (US), run by Instructor Jackie Zhang * KAIST (Korea), run by Jinseo Lee in Min Suk Kang's research group * National Taiwan Normal University (Taiwan), run by a student named NZ I've added these folks to this list -- welcome! -- and it brings our total to 43 institutions. The two new relays at KAIST and NTNU are the first relays in East Asia to join the campaign! Here is a reminder that if your educational-network relay has been running for a year and you haven't gotten your awesome EFF challenge coin gift and you haven't heard from Cooper, please reach out to me or him and we'll get your coin(s) on track. And lastly, we've been pondering how best to set up a community for the tor-edu operators to share information and grow solidarity with each other. I would feel bad adding more zoom calls to people's schedules. Maybe we should start a wiki to record advice / experiences / questions asynchronously? Let us know if you are interested to help brainstorm about community and we will happily work with you. Thanks for everything! --Roger _______________________________________________ toredu-announce mailing list toredu-announce(a)lists.eff.org https://lists.mayfirst.org/mailman/listinfo/toredu-announce ----- End forwarded message -----

1 0

Bridge "identity crisis" after reinstallation
by telekobold 26 Dec '25

26 Dec '25

Hi, about four weeks ago, I switched off one of my relays and two of my bridges running on Debian 11 ("Bullseye") systems after discovering the "not recommended" flags on the Tor metrics overview of those relays with the intension of reinstalling and reconfiguring the underlying VMs and relays the following days. (A few days later, I read on this list that those flags are not that critical, but unfortunately Tor doesn't seem to be updated for Debian 11 at the official torproject Debian repositories [1]). But as life goes, something always came up in the days that followed. However, a week ago, I finally wanted to reinstall one of the bridges. I'm using Offline Relay Identity Keys [2], so I created a new intermediate key pair consisting of ed25519_signing_cert and ed25519_signing_secret_key locally and copied them to /var/lib/tor/keys on my freshly installed VM, together with ed25519_master_id_public_key. Unfortunately, I didn't copy the old secret_id_key key file. I then realized that the fingerprint files under /var/lib/tor changed (despite that IP address, port number and identity key stayed the same) and that I wasn't able to connect to my bridge using Tor Browser. So, a week later (yesterday), I gave it a new try and did the complete reinstallation and configuration process again, but with the slight difference of also copying the files secret_onion_key, secret_onion_key_ntor and secret_id_key to /var/lib/tor/keys. This resulted in the fingerprint files being as they were on my old installation, but I read the following message at /var/log/tor/notices.log: [warn] http status 400 ("Looks like your keypair has changed? This authority previously recorded a different RSA identity for this Ed25519 identity (or vice versa.) Did you replace or copy some of your key files, but not the others? You should either restore the expected keypair, or delete your keys and restart Tor to start your relay with a new identity.") response from dirserver 66.111.2.131:9001. Please correct. So, I uninstalled tor, copied only the files ed25519_master_id_public_key, secret_id_key, ed25519_signing_cert and ed25519_signing_secret_key to /var/lib/tor/keys, which unfortunately also resulted in the above warning message. My question now: Do I still have a change to recover the "old identity" of my bridge, or did I "burn" the old identity now since the directory authorities apparently registered a new identity? Kind regards telekobold [1] https://deb.torproject.org/torproject.org/dists/bullseye/main/binary-amd64/… [2] https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/Offl…

2 2

You can delete my Relay from consensus
by code9n＠pm.me 25 Dec '25

25 Dec '25

Hi, Doubt you need to know this but you can delete my relay: 41D4F82AB54AE5C5FB8D3CD24B4FC84350EFEF03 from the consensus, etc. The price for renewing has gone up 69 per cent from two years ago and it's through put has halved for the last six months or so. Not sure if Tor just doesn't need it as much as it did or if the vps hosting provider (Hostworld) is throttling it. I'll start a completely new one early in the new year when I get some time. This one is dead and the vps hire has expired - I no longer have access to it. Just out of interest is my telling [Tor Project] this useful? Christmas-y regards, Pete

3 2

Do nameservers ever block an entire /64 if a Tor exit is in there?
by forest-relay-contact＠cryptolab.net 19 Dec '25

19 Dec '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I'm aware that some nameservers block Tor, so running a recursive local resolver on the same IP that traffic exits can be a bad idea. The usual solution is to buy an extra IPv4 and bind the local resolver to it. What about IPv6? Is it safe to simply make a new IPv6 on the same /64 and use that for recursive lookups, or are there nameservers that block the entire /64 that a single Tor exit relay is on? I currently use Unbound with "do-ip6: no" because I do not want to fail lookups and receive a BadExit flag if my entire /64 is blocked. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlFss8ACgkQBh18rEKN 1gugfA//UuYYhq7ATC1r3J/t5yHXB0bovAPzj519ICXGXaJ0TW86hY3PC5WzdYzk zKvKXArhQKm2Xdu9kh2w6YfETo3xTdUnTyLlBH1T/oeMamARUw1S+Osld4goiTS2 gsRzhN7hvzHw7NqMJLV+xEZQFBVLRg0Fi2E3oOqk5dBRbd5cMzpWZ4HiMqsY3jHH 6h5RY0HLk4HqPxGzAk0KRF056hDf4PmuGZuHSYsBR8PPMS4HwF/p6772KEK/ajBG VZr+v0Moi22dLMno+2SjkPy0rEOkRzOinOmqBLl6ajakn5lff0vR83eANTl3Vz2t bfP4PJ8bbraMVVdUEa5VobdDD8pGTbrryiB71gWO2AwS0GVnq8JIBK8pGSMAXmfc FNqxN/owYDSC+N3SlbOvK4YtIqbt5VKcU7nOuPzfBzm1cLMMq1NogzVN+FAdW9vr l9WD3AnKon6REM4ZpimDOZX8/5k0WKhhPm1TWmPa7ZB9NYyzQlbxEUmIIkQIXasW W0sVTeZ3vUwVQrUPilA8M0o8/cuWZleXs7RKNJP2T2r74olwUOw9E/afZXKxG9Hj daA1yUeD6tnUYk/pITddKHQ2V7Qd0BdHO2DMqQ71Bkcb7vTm/Ni45/jDaScaivz0 7vdCwPkC9k/sLEHHZ1kd33fjsGddILf7azSBRameI+9tgKZdw3E= =Z0tl -----END PGP SIGNATURE-----

1 0