- tor-relays - lists.torproject.org

OrNetStart AROI
by Michele Branchini 26 Nov '25

26 Nov '25

Hi there ! i was able to verify 19 out of 20 relays i operate on the OrNetStats website. sadly, the 20th has not passed the verification because i wrongly copy-pasted (tbh, that requestes some talent...) the fingerprint of that relay in the DNS. Now it is fixed, i have waited 24h, but still i can see the relay not verifying correctly... https://nusenu.github.io/OrNetStats/w/family/67ea5c7dbbbdc7c79990999b903c90… <-- family https://nusenu.github.io/OrNetStats/w/relay/91D66445EBE11BB058E9ED1ED92C7FE… <-- the relay itself I have also checked the relay family with https://aroivalidator.1aeo.com and there's all 20 seems verified correctly. ----------------------- "nickname": "TheShadowRoute19", "fingerprint": "91D66445EBE11BB058E9ED1ED92C7FED325F62E4", "valid": true, "proof_type": "dns-rsa", "domain": "antr.ax", "validation_steps": [ { "step": "DNS TXT lookup", "success": true, "details": "Found valid proof at 91d66445ebe11bb058e9ed1ed92c7fed325f62e4.antr.ax" } ], "error": null ----------------------- OrNetStats runs at which frequency ? Thanks, M.

2 1

Intentionally obtaining a MiddleOnly flag
by forest-relay-contact＠cryptolab.net 23 Nov '25

23 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Is it possible to run a relay that is not an exit *or* guard? I found a host with an AUP that states that Tor exit, entry, and bridge relays are prohibited. After messaging their customer support, they mention that middle relays are fine as their only concern is to avoid bringing in customers who harm the IP reputation of their services. Of course, their AUP is a little silly and likely stems from a misconception of the Tor network, especially if they allow middles but not guards. I did ask them if they could change the AUP to be more in-line with their intentions. Although I doubt any harm would come from it if I did run just a regular non-exit, it might be a good idea for me to avoid it becoming a guard, just in case they end up prioritize an over-literal interpretation of the letter of their AUP. Is there a way to do this, without intentionally interfering with the relay's stability or performance? Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkjYDIACgkQBh18rEKN 1gtD1w//ZUIYZmpqsuBF1sK56iMomZFBbqaf5L9ZRf+az034SVlVPvxtTGK95P87 wlkTF+VJzmkARPoH3tjsmBTl3VLtjnawUHstB7yrJ0QDfl7v9l2bEWZ5kMM1/aiB zDGrzoX8xN4Rq6VLFOkot0dB2nIy4MoQUkV0WYvKeHy+A0eQBgaObXXXEw86oNeX Vb2nO1fkEKLJZZgYyUsaIw7+duI1VWCAvHMz/sNk7sMXk5lNAFStrYYGdjlnqtZh wwQ0xFrRQhwlc9LS4FWjQRvSYMHxL8kFvzqKs98l/gGx1AZTXszW8BFf+rYWWTDY aICpMuqF72vtZZuLoaiCYuPro+SRcRbaC+zyt6GqkAbTzqok5wrr3D/gIJAV7vnH xpghje2y7+6JdssckMwtWanfQvE7yo3eVHrbxgwlrwL46UfdRphHiH5T1kaNE+hu Xxl9SSZj61iyk/k7P2rgihTFdhRFxgRPzviDrhd8neaE7dKp33mmWPr1mgM6vrK8 tb2a3Z6tWoPhxZcRAe6hFJDpqmZjOFO6JeTr6FngkG7R2ZlfGz/auB80dY7KETW4 cYEBwgbZ5qukDFfA3LwnLhKDNmQXpgHZET+vY40Cyl8uKtFt4hnlhllbvnP4NwVQ IYLYlKrRttEAempYGbvwTfyH7vqDCK6sin1i+IiXCuY/cP+r1II= =c7AV -----END PGP SIGNATURE-----

1 1

Sybil Attack on 2025-11-20 - please setup your AROIs :)
by nusenu 23 Nov '25

23 Nov '25

Hi, as some of you might have noticed, yesterday 2025-11-20 someone added ~900 new tor relays to the tor network. They used nickname schemes from other operators: * NTH * prsv * Quetzalcoatl * for-privacy.net * relayon * DFRI * bauruine ... For this reason I wanted to encourage every operator, especially the large once to setup their AROI. Here is a howto: https://nusenu.github.io/OrNetStats/aroi-setup Why? You get nice timeseries graphs of your relays. example: https://nusenu.github.io/OrNetStats/artikel10.org.html And it helps to **automatically** tell false-friends apart especially since families have become so large that we can no longer use that as a good signal because family must be splitted if they become too large for the descriptor limit. A good example is nothingtohide.nl, all of their relays have a proper AROI configuration and they verify properly: https://nusenu.github.io/OrNetStats/w/contact/aa738469b86e5ea8838d95eb2b8e6… Here are 3 examples of large relay operators where AROI verification fails (partially): If you are one of them or if you know them please ping them if you can: * quetzalcoatl-relays.org https://nusenu.github.io/OrNetStats/w/contact/b32573fcfbc780a4b9ef03425f676… * emeraldonion https://nusenu.github.io/OrNetStats/w/family/34933fa4f34ef248c8484749587002… * prsv.ch https://nusenu.github.io/OrNetStats/w/contact/65a4a24bfc53c4c6c0d312ce29ab7… kind regards, nusenu -- https://nusenu.github.io

7 8

Bridge Operation IPv6 only - possible?
by Jan Scherer 23 Nov '25

23 Nov '25

Hi there, I have two questions regarding bridge operations: Is it possible to run an obfs4 Bridge with external-reachable IPv6 only? I've tried to setup a "Node" on a seperate host, but in the same network as my relay. (VLAN-seperated) The idea was to open all external ports required for the tor part (on IPv4 and IPv6) and assign one different IPv6-Address as External obfs Port. I generally thought this could be beneficial, as with every firewall restart I get new IPs and potentially evade blocklists. From what I read there is a higher demand of bridges at the moment due to russian and chinese "ip whitelisting" attempts. Overall, the Networking Scheme would look like this (from Firewall-View) -------- WAN Source Target IP-Ver Port Desc. WAN Tor-Relay IPv4/6 30003 Allow Incoming Relay-Traffic WAN Tor-Bridge IPv4/6 30004 Allow Incoming Bridge-OR Traffic WAN Tor-Bridge IPv6 56120 Allow Incoming Bridge-Obfs4 Traffic -------- DMZ Source Target IP-Ver Port Desc. Tor-Relay "WAN" IPv4/6 * Allow Outgoing Relay-Traffic Tor-Bridge "WAN" IPv4/6 * Allow Outgoing Tor/Bridge Traffic -------- The Bridge is starting but freezes in a state before any major bootstrapping happened. (see Logs attached) I can see outbound and inbound traffic on the tor ports (30004), but not on the bridge ports. I assume the Tor part is "partially" working. In the Log: Is the last line [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:50652 - is that an internal Port or the port that I want to be 56120? Maybe someone could give me hint if this frankenstein construct is even supposed to work (like having a bridge with only public IPv6 Adress) and If there are any security constraints. Second Question: Should I exclude my own relay as Guard? Other thoughts: To improve privacy for the bridge even more, i thought about adding a second Interface to the VM, and work with IPv6 ULA and NAT for the needed Tor Connection. E.g. Pick any GUA from the External Availabe IP-Range and NAT it to ULA "fc55:c737:c747:c757::cafe" and do also Outbound NAT to the GUA again to not confuse the peers. But this is for another time. Last point, maybe it makes you smile about my stupidness.. I took alot of thought into physical security of my server, last Step was to trigger a Bitlocker-Lock, when the Chassis is opened. Unfortunetaly, the Chassis_Intrusion Implemetation of the Board is not great, so I ended up with connecting the Chassis Switch onto the CLR_CMOS Header. "Perfect Solution". When you open up the chassis, the system immediately resets and due to PCR Missmatch, the drive cannot be decrypted. I have removed any "Recovery Options" from bitlocker, so no 40 Digit Number you may enter in this case. If not planned, during a normal boot the TPM + Key-File + Pin would be needed to unseal the drive. I'm using TSME as additional layer of protection, so all of my ram is enrypted and cold boot attacks are not an option anymore. The measured performance impact was only about 6% in my case. It can be enabled in the Bios. To prevent DMA Attacks, I disabled USB-Support, Audio, SATA and there is even no free PCIe Slot or any other interface on the Board. Reason for all of this is that I may want to spread some more relays, and I cannot guard them or ensure that they are 100% safe from physical tampering, so I want them to just go down immediately when someone messes with them. If you have any more thoughts/improvements, let me know. After this long mail, I'm pretty sure you will all sleep well! Best regards and a nice start into the week! Joker

1 0

AROI Using proof:dns-rsa Not Getting Verified
by algo7 23 Nov '25

23 Nov '25

Hi there, I am trying to setup AROI for my exit relays following the guide here: https://nusenu.github.io/OrNetStats/aroi-setup I am using the DNS TXT records option. I already waited for more than 1 day; however, it seems like it's not getting verified for some reason. Here is the link on OrNetStats to my relay family. https://nusenu.github.io/OrNetStats/w/family/fb5e3cc1855a01ef74fc0843f63e3d… Relay Fingerprints: 2B51193205D091CC80B904D65721FF8DCBE51C96 61137FAC08E0AE62165D18FE8855CCCA26B6D631 Any help will be greatly appreciated. Thanks.

6 5

Running a relay and bridge on the same /24
by forest-relay-contact＠cryptolab.net 23 Nov '25

23 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I have several relays that each have two IPv4 addresses. One of them is used for an exit and the other is used to do recursive DNS lookups with Unbound, since some nameservers block Tor. The second IPv4 is not used for any other services. Often, both IPs are on the same /24, and sometimes they are even on the same /31 (for example, 203.0.113.38 and 203.0.113.39). Would there be any issues with running a bridge on the second IP? It has never been on the consensus or even connected to the Tor network. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkfVoUACgkQBh18rEKN 1gszdRAAyHUWkCH8Z54OMzyAmL/vU2jGNBSoSB/6EiaPaRoVhEj7AvboUeHYVzPk FA/9QKfYgkkHMJD6XHybbPxwAp9fQRJMmA3BOMYv5UES/KoMf3okbbh48xNnzT64 nQdw82FnFzuegfqCLymoBZULNBJdSr8vYAOi8JRCyt7igVvg/+tYCRCG1u1Sh5+P HogmmIhq4wQE329W9H/UmzBVLID1Zca+qAdvyVIdB95j/MxCz12TpIIcF0D6GsIj 41bjGJnQxbia2jyko/TMmgjNHwkE2oZhNpPclKSpVGwPbsplc62HRiX58Eucsr1B JKg3OSAKGzpz2pXYeTSClmNKmzL2vozSifd0vpRRAi3IXKQk/bKhG7St1bJH4LcT tH3w7pRZlbz2HnjLD2SKB/zau0axqaOOvPO9aCXi2Y2fSrvxjgLggtyIBy5szWZK 6s2HDCRMl6QS+FxMSB3ynincSoLildVEODzAOtzVoRWqlFAANr91/BfzSiWugaAj UPQX7CKJrsa3VOPjI3wi1qx36wQXXgWZ27o2/QSvqu0MiEF2ivuDwjRsNCyeDvu8 5J0SEQQ0aI1RdA4lUybcSUC3jUqlp3789ILEH90sOyXzAzgVT1HQ0ATHNit5oUkU K8FIYPWmFgNvpBybv4dErAnVMj/5p6yNP/KLr5PKr5wvJx9qp0k= =m7B2 -----END PGP SIGNATURE-----

2 1

tor log - Recommended versions are: 0.4.9.3-alpha (only)
by Felix 21 Nov '25

21 Nov '25

Hi, could someone please confirm: Nov 21 19:56:02.000 [warn] Please upgrade! This version of Tor (0.4.8.21) is obsolete, according to the directory authorities. Recommended versions are: 0.4.9.3-alpha Cheers, Felix

3 2

Short Knowlegde Sharing for DNS-Security
by providedlan＠arcor.de 20 Nov '25

20 Nov '25

1 0

New Relay Running Tor 0.4.9.3-alpha
by Tor Relay 20 Nov '25

20 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 To: tor(a)server-data.servebeer.com Subject: New Relay Running Tor 0.4.9.3-alpha – Fingerprint 29C57CA8D7E54CA674EA4CB88229F44815C2C207 (Unique in Italy) Hello Tor Project team, I am running a new relay on Tor 0.4.9.3-alpha. The relay is currently unique in Italy and fully operational. Fingerprint-Family: 29C57CA8D7E54CA674EA4CB88229F44815C2C207 Location: Bari, Italy IP: 109.116.219.235 Best regards, Tor Relay Operator -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5VwZ/q+VistGhWLUZTaefuiKQfUFAmkfqJcACgkQZTaefuiK QfUP6w/+LG7m/lcixbi1eZearrC2EaUnsuTWMsGDXX4nb7mM/ruehm6I82315oc5 iJsy2dhBoETDB8GJ25dnlg2TditypJIkzDTX8A5grtw9Hy2/pI+tFMl8bBm9HNC4 czwiidG4e20YpS8bvoZPH+cCv7sJeveNVq1mWm7XlZ3V6CA87ZZHIYdTG1kGpBDX D8JrVf60S72eD4StvDnckx4DZ2I50D/AVjwB1Qs47n/nxhxxsRJW3ZWVGxvLbQjx JTLQRgXKG5BvdP8tQpuv8mRF+rxe9Zbq7SF+67fPslbpuuBIGzxe5FPwdNns/J4r Ob2QFdT521KRaleUdD+SS173xFblMYCBvi1vC7NZiHlCvD0KogEuEDTTTLYWn89M +mhThkeNWZT8HHIfwfmArkdgeGpxKhQyGmuIbUQBbcIATEyIhmGDS30yweEUNSG2 z+0zpFn04qI+Nj7YkBFDhM76d9rNjqlPloHgZCptIzmyulixO7Z2Oo5ipzRQlz8f sYdA5TEkp68JvnPSW1/xnnEnrd4A8A8rAEe/qr5conBaegxIbRGfN83szD5G1aUN CfN/HvWQXGE8HTB5YMInwWnMRC1YRMZQ52YQV+Kb7wH9qI3FYvswYmfXPwks/kpO qH/dTAjLe0QPLYrw6TmgBHqbWCJMhvqOQuk0vviF2+RiQxY9ckc= =KWyG -----END PGP SIGNATURE-----

1 0

Accelerated depreciation of older versions?
by Nick Weaver 20 Nov '25

20 Nov '25

Was there an explicit decision made or an announcement about more rapid deprecating older server versions with the "Not recommended" flag? My test relay (tor.icsi-berkeley.org <http://tor.icsi-berkeley.org/>, I use it as my own guard on some tests) was running 0.4.8.18, and I noticed today that it had gained the "Not Recommended" flag which meant my client(s) would not connect to it as the choice of guard. I updated to 0.4.8.20 (as 0.4.8.21, although technically available, wasn't announced or linked to at the time on the Tor website). It lost the "not recommended" flag but regained it again as the current consensus now only has 0.4.8.21 and 0.4.9.3-alpha as acceptable versions. (so, well, update again)? Was this a deliberate decision or in response to a problem patched in 0.4.8.21 (and not announced as high enough severity to require immediate updating?) Is this going to be a policy going forward that relays should be updated within <12 hours of patch announcement? (also, tor26 basically likes everything BUT 0.4.8.21 because that hasn't gotten added to it, I think the Tor network might be disrupted if there is no agreement at all between the 3 authorities selecting recommended version, I think there could be a situation where there is no consensus on "recommended versions" if this isn't fixed) As of time of writing, from https://consensus-health.torproject.org/ moria1 client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha moria1 server-versions 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha tor26 client-versions 0.4.8.4, 0.4.8.5, 0.4.8.6, 0.4.8.7, 0.4.8.8, 0.4.8.9, 0.4.8.10, 0.4.8.11, 0.4.8.12, 0.4.8.13, 0.4.8.14, 0.4.8.15, 0.4.8.16, 0.4.8.17, 0.4.8.18, 0.4.8.19, 0.4.9.1-alpha, 0.4.9.2-alpha, 0.4.9.3-alpha, (Strikethrough: 0.4.8.20, 0.4.8.21 ) tor26 server-versions 0.4.8.4, 0.4.8.5, 0.4.8.6, 0.4.8.7, 0.4.8.8, 0.4.8.9, 0.4.8.10, 0.4.8.11, 0.4.8.12, 0.4.8.13, 0.4.8.14, 0.4.8.15, 0.4.8.16, 0.4.8.17, 0.4.8.18, 0.4.8.19, 0.4.9.1-alpha, 0.4.9.2-alpha, 0.4.9.3-alpha, (Strikethrough: 0.4.8.21 ) gabelmoo client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha gabelmoo server-versions 0.4.8.21, 0.4.9.3-alpha consensus client-versions 0.4.8.19, 0.4.8.20, 0.4.8.21, 0.4.9.3-alpha server-versions 0.4.8.21, 0.4.9.3-alpha -Nick

8 12