December 2025 - tor-relays - lists.torproject.org

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)

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

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

26 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-----

2 1

Re: Relay forest18 is still not on the consensus
by Marco Moock 24 Dec '25

24 Dec '25

On 24.12.2025 11:21 tztao <tztao(a)proton.me> wrote: > > Is India hostile to TOR? > > yes along with russia/iran and china which everyone knows India is new to me, in which way are they hostile? -- kind regards Marco Send spam to abfall1766571709(a)stinkedores.dorfdsl.de

1 0

Relay forest18 is still not on the consensus
by forest-relay-contact＠cryptolab.net 24 Dec '25

24 Dec '25

-----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-----

6 16

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

24 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

2 1

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

Fwd: Potential vulnerability found in your Tor Relay
by krishna e bera 19 Dec '25

19 Dec '25

Hi all, Just got the below notice from researchers. Is the stated vulnerability an actively exploited problem or is this a DoS attack by scaremongering? This topic seems to have been covered in https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijackin… but i am not sure how to apply it to my situation. I have turned off the Guard capability for now. Doubtful i can influence the service provider to get them to publish a new ROA. Is there another mitigation? Regrets to all who were using the service :( -------- Forwarded Message -------- Subject: Potential vulnerability found in your Tor Relay Date: Thu, 18 Dec 2025 23:57:20 +0000 From: ENGR - SIDR Hello, We are writing to alert you that your Tor relay(s) (Pasquino3) is/are vulnerable to active BGP attacks that could be used to de-anonymize users. The best mitigation to help protect your relay is to have your service provider publish a ROA for prefix(es) 209.44.96.0/19 at AS(es) 10929 with a maxLength(s) of 19. We are researchers from the University of Connecticut reaching out to inform you that your Tor guard relay with IP address(es) 209.44.114.178 (Pasquino3) is/are currently covered by a Route Origin Authorization (ROA) which has an improperly configured maxLength attribute. This makes it vulnerable to BGP subprefix origin hijacks, where a malicious autonomous-system-level attacker may announce a subprefix of 209.44.96.0/19 and misdirect traffic destined with a high (>99%) rate of success. Guidance on how to correctly set the maxLength attribute is contained in https://datatracker.ietf.org/doc/html/rfc9319. We determined this vulnerability using public data sets including relay information from the Tor consensus, the RIPEStat data for IP prefix, and ROA coverage information. Feel free to contact us if you have further questions. For further information on ROAs, see https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origi… If you are not a Tor relay operator and this message reached you in error, please let us know. Thank you, UConn Secure Interdomain Routing Group

6 5

automatic exit restriction policy does not include IPv6
by Marco Moock 18 Dec '25

18 Dec '25

Hello! I noticed that the implicit exit policy includes IPv4 localhost, RFC1918 IPv4 ranges etc, but does not include IPv6 by default, e.g. ::1, fe80::/10, fec0::/10 and not the public IPv6 itself. Is that a bug or a configuration issue? -- kind regards Marco Send spam to abfall1766003955(a)stinkedores.dorfdsl.de

2 3

Re: DirPort IPv6
by Marco Moock 05 Dec '25

05 Dec '25

On 04.12.2025 20:22 DiffieHellman <mailing_list(a)middlendian.com> wrote: > Reviewing a lot of contradictory information online and the tor > ChangeLog and torrc.sample, it appears that the DirPort supports > IPv6, but only authorities actually advertise directory information > anymore. > > There is still the secondary DirPort use, to serve the tor exit > notice (DirPort 80\n DirPortFrontPage /etc/tor/tor-exit-notice.html) > - which seems to be only targeted at those who see abuse and decide > to put the IPv4 address into a search engine and realise that it's a > tor exit (it seems that an assumption has been made that such sort > typically manages broken networks that are IPv4-only and therefore > listening on IPv6 wouldn't achieve anything). Thanks for the clarification. The note about this in the default torrc is outdated. -- kind regards Marco Send spam to abfall1764876123(a)stinkedores.dorfdsl.de

1 0