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

Out-of-Memory-Attack & DoS from Tor-Client
by ProSecureRelays 04 Dec '25

04 Dec '25

Hi there, i just want to report two partially successfull DoS Attacks on my Relay: First attack: Occured yesterday. The tor process showed massive traffic, much more my upload ( 45 Mbits) could handle. I don't know how in detail this worked, but I had receiving traffic at about 40Mbits and the relay tried to send about 100Mbits towards WAN. Because I didn't know if this was harmful traffic for the tor network, I finally pulled the plug and obtained a new IP after about 4 hours into the attack. I had the feeling that a short time, there was still unusual sending/recieving ratio, but all related to tor.exe and it stabilized soon after. My Guess ist hat a malformed packet was sent by tor, resulting in uncontrolled, unknown traffic to the WAN-Side. The Realy had 3 DDoS Circuits killed, rejected circuits and introduce 2 at unnormal high rate, also like 117 marked addresses. It sent about 250GB more then it recieved. The attack is also clearly visible in Tor Metrics, a massive spike in written Bytes can be seen. Fingerprint: 8AFE4E6F05234B0184327C052B09F10191EAFAF3 Second Attack (today): Today at about 2 p.m., the memory of the relay spiked to maximum (8GB) and additionally 22GB of virtual memory was used. This caused the process to die, with an out-of-memory Error. This also must came from a malformed packet in tor. Is there any known method to circumvent both of these Issues? In the first event, i don't know if the error could have cleared self after some more hours. Regarding the memory issue, i think this must be resolved in the tor software itself, allthough I thought about adding 64GB of RAM and 256GB Page-File, just to see if it makes any difference in case of attacks. But I don't think so. Best regards, Joker

6 7

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

DirPort IPv6
by Marco Moock 03 Dec '25

03 Dec '25

Hello! Does DirPort support IPv6? If I use it without address, it only listend on the IPv4 socket. If I use DirPort [::]:9030, it cannot start up. -- kind regards Marco Send spam to abfall1764741021(a)stinkedores.dorfdsl.de

1 0

Small update to Relay Operator Expectations Policy
by Georg Koppen 02 Dec '25

02 Dec '25

Hello! We just pushed a commit to update our Relay Operator Expectations Policy[1] to version 2.1. It comes with a clarification for section "3. Make sure your relay isn't broken", where we now say "Don't block outgoing connections." instead of "Don't firewall outgoing connections." This makes the point we try to convey in that particular part of the policy clearer. For context, this topic got raised in a recent thread about Hetzner related issues[2] and, while we improved the wording of our expectations document and updated the bad-relay criteria accordingly, we are not done on that front yet. There is still a ticket open for investigating potentially acceptable solutions dealing with the underlying issue at Hetzner on a technical level[3]. Depending on that outcome and after thinking through filtering/rate-limiting concerns we might need to update the expectations document in the future again. Thanks to everyone who helped so far both with the technical investigation and policy discussion. Georg [1] https://community.torproject.org/policies/relays/expectations-for-relay-ope… [2] https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torp… [3] https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/105

1 0

Split Horizon Tor+Mastodon
by Jon 01 Dec '25

01 Dec '25

Hi All, I'm working on https://domum.social a Mastodon instance that does not collect email addresses and only allows authenticated access via the tor hidden service URL: http://f3rz5puehnq7dfqqwajxu3izuovb6wqepof3prqesle76qyfivlfxgyd.onion Federation to and from the regular clear-net fediverse works as normal. While there's a number of Mastodon instances that have onion addresses and at least one I found that doesn't block well know disposable email addresses like sharklasers.com, this puts a high burden on the user. My technical goal with domum.social is to make privacy the default so you can't accidentally login outside Tor and there's no opportunity to enter an identifiable email address. Socially a lot of documentation is needed so that a general audience can understand how to evaluate their own threat models and manage their own operational security. I've been working on the site off and on since last April and running live with myself as the only user for about a month. Before taking on real users I want to open the concept and implementation to wider scrutiny. I'm an infrastructure person not a a programmer by trade so hopefully it's not too ugly. I tried to keep code over rides to a minimum with nothing in tree. This repo has all the Mastodon related overrides: https://github.com/domum-social/mastodon-additions There's a bit more special sauce in the proxy config to disallow access to the authentication endpoints on the clear-net site, and to ensure rewriting of clear-net URL that mastodon generates to the onion URL when accessed through the hidden site. The mail server config is also a bit special so most users get their fake internal email discarded but Admins and Moderators (who are nonymous) can get real mail deliver to be notified or any issues. Depending on feed back, I'm hoping to start a limited public beta in about a week. Any and all thoughts are appreciated here, or on Mastodon @jon@domum.social Thanks! -Jon https://metrics.torproject.org/rs.html#details/A53C46F5B157DD83366D45A8E99A…

2 1

Regarding DNS reliability testing for relay operators
by relayadmin 01 Dec '25

01 Dec '25

Hey all, I've spent a good part of the fall learning about Tor, and I'm excited to start contributing as a relay operator. DNS seems to be a significant point of confusion. I posted about this a few weeks back (https://forum.torproject.org/t/best-practices-for-dns-local-vs-external-res…) and got a helpful response from NTH, but there still seems to be uncertainty around DNS performance. That inspired me to run some tests that might help current and future operators set up more reliable and private DNS. My plan is to run three separate hosts with identical OS/resources and torrc configs, but with different DNS setups based on the three most commonly recommended configurations: - Node 1: Runs a local Unbound server using itself as the resolver - only contacting recursive resolvers from the node. - Node 2: Runs an Unbound server on an external IP used by the relay as an upstream resolver, ensuring queries aren't made over a Tor IP. - Node 3: Uses the ISP's local DNS configuration (no changes from the “out-of-the-box” setup). Is there another configuration worth testing that I haven't listed here? Have anyone here conducting similar testing? Feel free to email me directly. I still need to get more comfortable with Prometheus and Tor metrics before I feel ready to run the nodes, so in the meantime I'd really appreciate hearing your thoughts on this kind of contribution. Happy December 1st everyone. Riley

2 1

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