- tor-relays - lists.torproject.org

Proxy fairness improvements in Snowflake
by Cecylia Bocovich 27 Oct '26

27 Oct '26

TL;DR: We're deploying a proxy rate-limiting feature to defend against blocking attacks. No changes to proxy configurations are necessary. Make sure your Snowflake proxy is up to date. If you run multiple proxies behind the same IP address, you may see some rejected polls or a small decrease in the number of connected clients. This is expected and your proxy will continue to poll the broker and collect clients. We've been working on some features lately to improve the resilience of Snowflake to proxy enumeration attacks in which a censor can attempt to block Snowflake by blocking enough proxy IP addresses to make the system unusable. Such an attack is possible if a censor runs a modified Snowflake client and logs the IP addresses of each of the proxies it is matched with. A censor can then add these IP addresses to a block list, preventing a user in the same region from successfully connecting to those proxies. Snowflake naturally has some resistance to this type of attack because of its large proxy pool of around 150K unique IP addresses, thanks to this community <3, and high churn from many of these proxies joining and leaving the proxy pool each day[0,1]. However, high capacity standalone Snowflake proxies present a unique challenge: they are extremely useful because of their stability and generally unrestrictive or nonexistent firewalls and NATs, but they are also the most frequently matched with users and therefore are the most likely to be blocked if an enumeration attack were to occur. A few years ago, Roger posted the results of a snowflake blocking experiment[2] that found this blocking attack to be particularly effective against users behind more restrictive NATs, because these users are proportionally more likely to be matched with high capacity standalone Snowflake proxies. To help balance the distribution rates of proxies, we've designed and implemented a proxy fairness proposal[3]. In this proposal, we equalize proxy polling rates by interactively letting each proxy know when to poll next[4], and rate-limit proxies that poll too quickly[5]. You can read more about our justification for this in the linked issues, but to summarize: by slowing the rate of our higher capacity proxies to match lower capacity proxies, users are more likely to receive a proxy that is lower capacity and therefore less likely to have been enumerated. This change will also defend against a potential denial of service attack by malicious proxies flooding the network. What this means for Snowflake proxy operators: - If you are running a standalone Snowflake proxy, make sure you have the most recent version. - If you run multiple Snowflake proxies behind the same NAT, you may see some rejected polls because of the rate limiting feature. The rate limit is per-IP, intentionally, because IP addresses are what censors will block in this kind of attack. This is normal, your proxy will continue to try again. - You may or may not see a change in your usage stats. If you do, I'd love to hear from you on this thread about what you are seeing. This shouldn't affect overall capacity, but may mean that proxies reach their capacity more slowly. - There has been a change to the poll-interval command-line option. This now specifies a default or initial poll rate. The proxy's poll rate will change interactively, based on information from the Snowflake broker. We've updated the README to reflect this. We are planning a short 2 hour trial deployment of this new broker feature on Tuesday, October 27th at 15 UTC[6]. During this time you may see the above described changes take effect for your proxies. I will post an update to this thread with metrics and the outcome of this trial. If the trial goes smoothly, we will schedule a more permanent deployment of this feature. As usual, please reach out if you experience bugs or see drastic drops in connected users. Thank you for running a Snowflake proxy. The growing number of volunteers has made a huge impact on Snowflake's blocking resistance! [0] https://bamsoftware.com/papers/snowflake/#proxy-churn [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… [2] https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@… [3] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… [4] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… [5] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… [6] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

2 3

Authority Amplified Attack
by Logforme 26 Oct '26

26 Oct '26

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 Like many relays mine has been under attack for a while now. Recently it has however become worse. Because of the DirAuths. After having restarted the relay a few time in order to upgrade the tor program in the vain hope there might be a fix for the attack, the attacker now only have to spend a few hours every few days on my relay. The rest of the time it is flagged as non-stable and gets hardly any traffic. Once the DirAuths figure the relay is stable the flags return, and so does the attack. And the DirAuths promptly removes the flags and we go another round around the loop. If the torproject can't find a programmer to fix the actual issue can the DirAuths at least relax the requirements for the stable flag?

5 5

Shutting down my ~40 guards
by forest 26 Oct '26

26 Oct '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Within a matter of minutes, quite a few of my relays have come under attack again. As there has been no progress in mitigating the attacks despite several new releases of Tor coming out and no information from the devs about any in-progress mitigations or even plans to develop a mitigation, I'm no longer able to run relays that are eligible for the HSDir flag. The attacks have been causing financial strain to me and straining my relationship with my hosting providers, many of which I have spent significant effort to convince to allow Tor. If someone knows of a mitigation, can poke the devs to write one, can point me in the right direction for writing my own without getting my relays marked bad for behaving in a non-standard way, or knows of a way to get my relays blacklisted from the HSDir flag besides just setting DirCache 0 (which also prevents being a guard), please tell me. This is a difficult decision, but if there's really no plan or progress in developing a mitigation for these attacks, I'll be shutting down ~40 guards over the next several days. I just don't know what else to do. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCasyPGgAKCRAw+TRLM+X4 xq01APsF9oxsd74W9sK/cO+xnt4HWZWZ/A7MWc8s2WUHN7telwD/SeoVfuzjaJIM 0NcyOUQVi9jzqkqfr4JEnASneNkh8g0= =dFuQ -----END PGP SIGNATURE-----

17 47

Testers wanted: replacements for the stopped tor-ddos scripts and its relay lists
by Enova Maker 21 Oct '26

21 Oct '26

Hello, The `Enkidu-6/tor-ddos` project was shut down in May and its relay lists are no longer updated. I have published replacements that keep the same commands: - https://www.google.com/url?q=https://github.com/EnovaMaker/tor-ddos-compat&… — same scripts (`download.sh`, `multi.sh`, `update.sh`, ...), iptables/ipset, same set names. Run the download line from the directory of your old install and it offers to reuse your addresses and ports. - https://www.google.com/url?q=https://github.com/EnovaMaker/tor-relay-lists&… — the lists, rebuilt from the Tor consensus, under the same file names except `dual-or`, `overloaded` and the Snowflake lists, which are not covered yet. If you read them yourself, change `Enkidu-6` to `EnovaMaker` in the URL. - https://www.google.com/url?q=https://github.com/EnovaMaker/nixos-tor-anti-d… — the same idea as a NixOS module, using nftables. One difference on purpose: as its README describes the rule, an address is blocked once it has more than two connections, which a one-connection limit never reaches; here a source is blocked after repeated refused connections. It is not production-tested, and I have not seen a real `ipv4.txt` from the old scripts, so I would like to hear from anyone who migrates: did it pick up your addresses and ports, and did it drop any relay that should not have been dropped? MIT licensed. Independent of the Tor Project and of the author of tor-ddos. EnovaMaker

2 2

Re: How is this attack causing 900 Mbps download and 100 Mbps upload?
by Khan Krum 19 Oct '26

19 Oct '26

Hi forest, and everyone, I would like to share a further update following my earlier reports about abnormal BEGIN_DIR activity on three non-exit Tor relays. We have now completed a reproducible retrospective analysis of another prolonged incident on October 17–18, following the earlier episodes on October 4–5, October 8, and October 12–13. This time we had two independent monitoring systems: - Tor Sentinel, collecting standard Tor MetricsPort measurements, including BEGIN_DIR activity, circuit counts and Tor process metrics. - Linux OS Sentinel, independently collecting host and process resource indicators, including CPU, memory, swap and Linux pressure statistics. The second system was added after the earlier incidents revealed that MetricsPort can become temporarily unresponsive during severe overload. Our main observations are: 1. Two ARM relays, hosted by different providers (Hetzner and Oracle Cloud), again experienced substantial, prolonged BEGIN_DIR-related workload. A third, smaller Oracle AMD relay did not show comparable BEGIN_DIR activity. 2. The two affected relays showed different resource profiles. The Hetzner relay experienced very low available memory and substantial swap occupancy. The Oracle ARM relay showed considerable CPU pressure and more monitoring failures despite retaining a much larger memory reserve. 3. The Tor processes remained running. A bandwidth configuration change and reload reported on the Hetzner relay did not immediately end its prolonged abnormal state. 4. Locally observed HSDir flag transitions did not provide a simple explanation for the onset of the workload. We are distinguishing these observations from independently verified directory consensus changes. 5. The recorded BEGIN_DIR peaks are lower bounds on the maximum successfully observed rates, not necessarily the true maxima, because measurements can be lost during overload. We have preserved and validated the underlying measurements and analysis scripts. However, in accordance with Tor’s relay-operator privacy expectations, I am not publishing high-resolution traffic or host statistics. I would be happy to discuss an appropriate private channel for technical review. A few questions for operators and developers: - Have others observed MetricsPort timeouts or degraded responsiveness during comparable BEGIN_DIR workloads? - Have Tor’s MaxMemInQueues protection or circuit-killing notices appeared during these incidents? - Is there any progress on understanding why the experimental BEGIN_DIR rate-limiting approach discussed earlier did not appear effective? - Can Network Health or the directory-authority community help clarify whether overload-related descriptor or consensus effects might explain some of the observed flag changes? - Would a coordinated comparison of daily incident summaries from independent operators be useful? I do not have evidence identifying the origin or intent of this traffic, and I do not want to imply that all reports necessarily have the same cause. My goal is to contribute reliable observations and help identify what further evidence would be useful. Regards, KhanKrum

1 0

Looking to interview Tor relay operators (online or at FOSDEM)
by Jules Dejaeghere 17 Oct '26

17 Oct '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!*

6 14

Re: How is this attack causing 900 Mbps download and 100 Mbps upload?
by Khan Krum 14 Oct '26

14 Oct '26

Hi, I run three hobby relays and I seem to be seeing the same behavior on one of them. I compared two similar ARM, 2-core, non-exit Guard+HSDir relays, both running Tor 0.4.9.13. On the affected relay I measured 41,240 BEGIN_DIR streams in 61 seconds (~676/s). The Tor main thread reaches about 100% CPU, ntor onionskins are being dropped, and traffic is strongly asymmetric — roughly 2.2 MB/s read vs 7.1 MB/s written. On my other Guard+HSDir relay, measured at roughly the same time, I saw only 148 BEGIN_DIR streams in 60 seconds (~2.5/s). That relay carries much more traffic (~15 MB/s in both directions) and appears healthy. So in my case, simply having the HSDir flag does not seem sufficient to trigger the issue. One relay is affected, while another Guard+HSDir relay is not. I’m only a hobby relay operator, so I’m posting these numbers mainly in case they are useful for comparison. Regards, KhanKrum

4 5

How is this attack causing 900 Mbps download and 100 Mbps upload?
by forest 14 Oct '26

14 Oct '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I'm experiencing a very strange high-bandwidth attack against my exit F79C822281CB1001E589296C80ABA6EA5DC7E36A. At first it was a directory fetch attack, slowing it to a crawl due to upload exceeding 700 Mbps (while download was never over 50 Mbps). I added "DirCache 0" to torrc as a stop-gap measure, but after reloading, the attack has changed and now *download* is excessive, showing 900 Mbps down and 100 Mbps up. How is this possible? What kind of attack could cause such asymmetric load in the *download* direction? I confirmed with nyx that it was downloading at nearly 10x the rate that it was uploading. This relay rarely exceeds 100 Mbps bidirectionally under normal conditions. Of the 60 relays I operate, this is the only one that appears affected. I'm urgently in need of advice for troubleshooting this. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqCn9gAKCRAw+TRLM+X4 xuy7AQCmmd6TvF4MSr8c04pbHVl3Emw0SufRO0Vxg4XFnz7jtQEAnE7u4Y653gn6 vdzmiDOP9VJT9fDDSP4LXqu64XHh9gE= =9jHQ -----END PGP SIGNATURE-----

11 26

1AEO exit relay DNS health checks now classify upstream recursive resolvers
by Tor at 1AEO 14 Oct '26

14 Oct '26

Hello, Exit DNS health checks now include the recursive resolver each exit used. Results are on https://exitdnshealth.1aeo.com (raw) and https://metrics.1aeo.com (aggregated and specific) Methodology Each exit is probed with unique values with tor.exit.validator.1aeo.com to bypass caching and capture the authoritative query's source IP. Upstream resolvers are classified once a threshold of ~25 queries per relay is met: Local: Query originates from the exit's IP or its origin AS (including hoster-internal resolvers). Public: Google Public DNS, Cloudflare, Quad9, OpenDNS, or Freifunk München. Other: Uncategorized third-party resolvers. Current Network Snapshot (12 Oct 2026) Across ~2,600 exits with sufficient query volume: Local: ~67% Public: ~22% (~510 exits: Google ~10%, Cloudflare ~8%, Quad9 ~2%, Freifunk ~1%, OpenDNS <1%) Other: ~12% Endpoints Per-relay status: [https://metrics.1aeo.com/relay/](https://metrics.1aeo.com/relay/)<FINGERPRINT>/ (DNS Health → Upstream Resolver) Aggregated dashboard: [https://metrics.1aeo.com/network-health.html](https://metrics.1aeo.com/netw… Raw JSON: [https://exitdnshealth.1aeo.com/latest.json](https://exitdnshealth.1aeo.com/… (metadata.resolvers, results[].resolver) Prometheus scrape: [https://metrics.1aeo.com/metrics](https://metrics.1aeo.com/metrics) (aeo1_exit_dns_public_resolver_share_ratio, aeo1_exit_dns_resolver_queries_count) As a reminder, community best practices recommend running a local non-forwarding recursive resolver (e.g., Unbound or BIND on 127.0.0.1) rather than pointing to centralized public DNS providers to prevent upstream query correlation and metadata logging.

2 1

Relay suddenly stopped relaying traffic but is still in the consensus
by forest 12 Oct '26

12 Oct '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Yesterday, one of my relays suddenly (within minutes) went from passing about 5 Mbps to passing nothing. The traffic rate dropped off as rapidly as if it went into hibernation. The consensus still says it is up. Nyx does not show any indication of failures and all directory authorities are able to reach its ORPort. There's no network censorship occurring as far as I can tell (my other relays can reach its ORPort). Nothing is out of place in the logs, but Nyx still reports an average rate of 1 KB/sec. Why is this? The relay is 0EF2A357140FCBDAE2F948CC2228909695B81B35. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCasLlCAAKCRAw+TRLM+X4 xkrfAQClP3aXODcrcvS9KOgj7tPCUeB9holpR1kpSrpF99qAFQD9EjjMBr3lKZgF F3RLEbRjTQDULtmqSqMbkJaA/oW4FQg= =6Xg7 -----END PGP SIGNATURE-----

3 3