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

upcoming CIISS update
by nusenu 09 Jan '26

09 Jan '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

2 3

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

Add CGNAT 100.64.0.0/10 to Default Exit Relay Reject Policy
by admin＠likogan.dev 03 Dec '25

03 Dec '25

Hello, I've noticed that the non-publicly routable CGNAT subnet of 100.64.0.0/10 is not in the default exit policy reject list like 192.168/16 and 10/8 are. This range is not publicly routed, and should never need to be accessed from a Tor exit. Tailscale and other ISPs use this block. How many exit relays connected to a Tailscale network are unknowingly exposing all of their other Tailscale devices to the Tor network? ISPs may be less willing to allow exit relays if there are bots using Tor to toy with the ISPs 100.64/10 range. Maybe there is something I am missing for it to not be included? Thanks, Likogan.Dev

3 2

Re: Bridge Operation IPv6 only - possible?
by ProSecureRelays 01 Dec '25

01 Dec '25

Hi there, the Bridge is working right now as expected - i was confused to see the boostrapping not in the CMD but finally found it in the Notice file. Beginners fault, I was literally working the whole time. For testing I added IPv4 Support, but I will remove it now, because I'm afraid people getting busted as tor user, when Relay and Bridge-Obfs-Interface share their addresses - and I think for good reason. The simple torrc option "IPv6Only" should do the trick. Is there any additional site to look up the bridge aroi state? From what I saw was 1aeo only tracks the relay stats (huge thanks for this!) Best regards Joker Von: Jan Scherer via tor-relays [mailto:tor-relays@lists.torproject.org] Gesendet: Sonntag, 23. November 2025 20:35 An: tor-relays(a)lists.torproject.org Betreff: [tor-relays] Bridge Operation IPv6 only - possible? 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

2 1

Getting IP reputation services to use ExoneraTor?
by forest-relay-contact＠cryptolab.net 30 Nov '25

30 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. A discussion with a hosting provider led to them making a suggestion after I showed them https://metrics.torproject.org/exonerator.html, so I thought I'd explain his suggestion and post it here. Nowadays, a huge number of hosts are familiar with Tor and sympathize, but do not allow exits because it severely taints their IPs and makes them difficult to resell afterwards. With the rising costs of IPv4, it is a deal-breaker even if the host would otherwise be fine with exits. Obviously, convincing IP reputation services and blacklists to make an exception for Tor is impossible: It goes against their mission. But has anyone tried advocating to these reputation services that they remove exit IPs from blacklists once they are no longer exiting traffic? This would reduce the number of false positives in their database without increasing that of false negatives (which is all they care about). I imagine hosts would be much more amenable to hosting exits if the subsequently blacklisted IPs revert to being clean as soon as the exit operator leaves. After all, "if I'm your customer, the IP ranges I use will be tainted for a long time and potentially unsellable even after I leave" is not going to inspire as much confidence as "if I'm your customer, the IP ranges will only be dirty while I use them". Is there anything to this? Large exit operators can just register their own ASN and simply not care about blacklists, but most operators are not going to be able to do this, especially if they run just a couple relays anonymously and on a tight budget. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkrjRgACgkQBh18rEKN 1gvHJQ/9FJBMMFJ86hCR1OE4n9ONwAsP7CxB4MBO58mUz+bN40Ngzv/N+Ih0BaQf 8qYEcHeEaYp7IB+/OFJS3hTOZDZYCdXU7nocxZgZ5l4k4e68JnyyNSio/zMu5tHk GUeQd10wZXxQnzBgdfDlj2tyCMUkWlzcvgxTaqk7scHuEk1kwfyixvcfbgMQL7T8 nWqik8BTzKYuS6zimks4MQsl8viE2dpOaWkz4xtm4EPUlQv1kh2N3c7JO0vFyC3s Q1ad/4VmlZQ3lgOO++0B3CSJ/6Fh2hYGYJm8B2Fe1nSdZ/SY1+mLYr0KupM53tEL FKsnXliqyIMVExBW5MlxoGlK4AQ3AkbrafkpUSPvNsvjmu94GHrg2Y1jcefSelFO zd34lfRmDaNE1yoxL1ehxYIEJGbwkMnxU4+FC5tnHxcWM8gtE499kFu4+5JCFiBu i2ldLycdIEaez2mb8VbXHXdwjAQy8dVlFaHVua26riirVoKmTgKEJ+wnVkCbAF8W 8ZUQVVRQIwJyo2dlcNGrwGwZ5BtzXFtYiJfmqE4yesc7MESQsqb02kWlPVEVTCyq UMDzVa+W08xhTr+c9iaFIC8scmZCoI0zOpFiqBUofIR9NWKszccXrJbOdF3vDkNJ ZGquAzEnrwwhB9Zj3QLoz05AUzlmLtWd0u30gqZ8zMMx5KSs9iY= =IVGe -----END PGP SIGNATURE-----

1 0

Exact criteria for receiving a BadExit flag
by forest-relay-contact＠cryptolab.net 27 Nov '25

27 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I contacted an exit operator who had BadExit flags on the same host that I run an exit on and we discussed possible reasons for this. Eventually, we jointly set up a new relay on that host and I configured it exactly as I had configured my own relay, and it still obtained the BadExit flag. So far, these are the exact steps I took to configure it: - Unbound is configured to use a second, clean IPv4 - sysctls are tweaked to ensure conntrack does not drop connections - torrc is configured with safe, sensible exit defaults And it still obtained a BadExit flag. We had discussed whether there was a possibility that his family was "tainted" and somehow the BadExit flag was being applied to new exits on his relay family, but starting up a new relay unrelated to his did not help. We tried disabling Unbound and instead using a popular upstream DNS resolver, but that did not prevent a BadExit from being issued either. What other troubleshooting steps are suggested? The provider does not censor or block anything, and I have been successfully running an exit on their infrastructure for more than a month, but when he sets one up, even if he configures it identically to the way I configure mine, it receives a BadExit flag within a matter of days. The criteria for issuing the BadExit flag do not seem very clear. Since it is not a flag intended to be issued to malicious exits, I would like to understand the exact criteria for being issued a BadExit, beyond the vague explanations that I can find on the Gitlab. Note that I am only asking about the automated flag, not about the (potentially sensitive) policies behind determining whether or not a relay is malicious and should be manually excluded from the consensus. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkmGG8ACgkQBh18rEKN 1guZhxAAxUFcZm1SuoCO5OOST915LtPPmZ6mizq+NUfS3tPoJj6zKRd/grZJYIRj TZzw7JqK62ajtMJLQcLLKuMNMHYZmzr0DP8jVo/JAoh/rcGIqXL+jWIupDDxIQG7 Mf25OF6OrhNb23HTwrudJIiM/PFH6Yyoj0hlDBxpSu3IcopP9xxPwPKYXQjgaZEx mJPpbTb86vrs1TmBQ7C7W6pBoq6zOtne2NfqC6SJ1UNpk/dYxQnknuFYLDeaSPdz qNkh/h2Ua0a0ASGswxTRatd2epkDKrJHoVJ5t/WBPnzPOUJdo6D26oLr1bKzSTM1 +nKkd5ws5b2d8Fi+FQk7LbgiLBSdGAIFL3bBL3FD5ERE+1LkOTaOs9wR0dlIFNRV 4draROjsgfYIw0LavO+O8EEbS5R5xyf5RNIueNMpqbV/IGhoYLYUUfdqITB1swHr jFaEUoNIFAvBS1qp+9ApjmQJ/J2CiPZJ7Su73v6vA9Qq6Amv3ruMK+w5sqO1BpFB V9L/pr/ZB3619SyqMVN2e+M58xDumwwMTHK1AVIGHZLlff5VYR4rBtqXR1T0qPKl AdliLh39C+oBFD0q+12tbucjjJjg8LiiZfo7KReZDpN78zJWxtR+Z57/XfXYDqJd 9FDJdYAm4qLa9wEzAUslEdrfGnokYJQQcI07eNqPFgnl4B80V4I= =N2Ia -----END PGP SIGNATURE-----

2 2

Could you post an i386 build for Trixie?
by Dawn Flood 26 Nov '25

26 Nov '25

Good Day, I am going to upgrade eventually to Debian Trixie 64-bit, but it would be so very wonderful if a i386 build with the most recent stable changes could be posted here with the appropriate updates to the 'Release' file (to include the i386 architecture): https://deb.torproject.org/torproject.org/dists/trixie/ Thanks so very much!! Dawn

3 5

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 24 Nov '25

24 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