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

abuse report from relays in family 7EAAC49A7840D33B62FA276429F3B03C92AA9327
by Dimitris T. 29 Oct '25

29 Oct '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.

13 28

Being banned?
by Brian Henderson 26 Oct '25

26 Oct '25

Hi, first time using this group so I hope I am not braking any rules. I wanted to ask others if they have noticed themselves getting blocked from certain sites (such as banks) because they are running a tor relay? I have checked my ip on various lists and it seems two rarely used lists have a ban on a group of numbers from my isp, but not my number specifically. I have been using my bank for years from this connection, now i seem to be blocked and it coincides with starting to run a tor and i2p relays. I have tried to access the site from different software but it just hangs. The bank claim they are not blocking me. Anyone else had this type of problem? Brian.

6 5

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 25 Oct '25

25 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > IPv6 is locally resolved by each relay. If this fails, probably > because some DNS servers are IPv4-only, the relays shall forward > their queries to 1-2 central DNS resolver with IPv4 addresses. That would probably be doable, but it would negate the privacy and the security benefit of running a local DNSSEC-validating recursive DNS resolver. When I run my own, I can be sure that it's using a local copy of the root zone, that it's using QNAME minimization and aggressive- NSEC, that it's up-to-date and is aggressively caching negative answers (which are very common over Tor), etc. Perhaps I could have the resolver prefer IPv6 and if the nameserver doesn't support that, it could fall back to the exit's IPv4. If the nameserver blocks Tor, *then* it could be sent up to some privacy- friendly upstream resolver. I don't know if Unbound can be configured to do that natively. It might take a small patch. > The overlap of DNS servers that are IPv4-only and block Tor relays > might be small enough to tolerate the issue or just use a friendly > public resolver for them as fallback. I don't think it would be enough to tolerate the issue. Failures to get answers from big nameservers doesn't just break a few websites. It can break an entire zone. You may find that all .hu domains that lack IPv6 will become unreachable. Using a friendly public resolver as fallback, or even falling back to a high-latency resolver on one of my other nodes, is probably preferable. > In any way, I hope you enable IPv6 on your relays (start with DNS). > Because the IPv4 shortage only gets worse over time, and enabling > IPv6 is a (partial) way out, even already today. I have IPv6 enabled on all my exits that support it. Some of them do not support IPv6, but that is the fault of budget basement datacenters running in Romania, and not my own network config. ;) Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj84v8ACgkQBh18rEKN 1gseMRAAi/g6rB/Bj84IepqIB2y+BVW4klxae7IYrSFK4YNezlpNjCp4BWZIZTlS lNL3jD6w7iJmJyxKXFmpwn+bEmv5sdin15j2LHn8486L+F72XyVmogHH5rQ7Bxn8 yITnjr8EBsfEWrLZQRmmPjfqgSXXUo2r8JDN42KdivASzFh4skrQY/N8f79/fKtL qJp5FohU+Z4BFRCkgdR4wNIpQeysp6cxm3cyOVUay/ZnWNB2yQDaoT3JKsV8JlDD nzIwLqYBiNZp/qALoVWEqdy0Ohzq1Sj6WtHZHbvlQNvOH2G2nAYwRFzcHYlrdrjz TRY91oqeFgEv0TeeXbc+rcSbPwz34mQTXy80VxhuMhNmihrwI7h6kDHWQ9FNTu6I joOZIOJWTxRNaAWLEauk2j+xSOxB3wHfuyjLtXfZjyGzHiicVzi126DKf8nqWaJX hmOnlM0pdeZwgYojG9j777pLN+K01QEK8JVvtrKvHXxVx4k0jbQ/9EcdhHG5PnNd skeCiex+8x7vnSH8/nr4l3x291gKr8vFJqIK64Whq2niAkK8xw6YrIYlvVUSD/4/ HESlYMZW7STS6f3VdnzW9fvYFU+voiQ4wCLCn5wwq/VoI1CxDYRX8QdnT+ra2ogF HgEBplSu3MNQpDAhbYRJy2FVYh9BlcdgXmYrd0yoyK14x2mrzvA= =2u/4 -----END PGP SIGNATURE-----

2 1

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 25 Oct '25

25 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > You should definitely try setting up IPv6. Essentially, your problem > is rooted in the limited number of IPv4 addresses. With IPv6, you > most certainly can have more than one IPv6 address on every VPS for > free. Using IPv6 wherever possible tackles the root issue. This would only work if all nameservers support IPv6, no? I would still need to use IPv4 for the nameservers that don't, which means continuing to pay for the extra IPv4. What I'm thinking of doing is choosing a single reliable exit in each geographic location that I run, and using it as the upstream DNS resolver for all the other relays in the region. Thus I can use one relay in the USA to serve my relay in Canada, and one relay in Moldova to serve other relays in Europe. I would only need to pay for an extra IPv4 for each geographic region, and wouldn't have to suffer from the nasty >200ms latency incurred through transoceanic cables. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj7ch4ACgkQBh18rEKN 1gu6jBAArMfWI6mXe6Ce+9UUQ8FQPgxDYjiySBij3QqN3NmM2N0TGxU/+wjldLrP wE/1zFjuTTQfZsOXJcLd13kmiqpt4jFRVAe+d0vpdfMkIppbDRmYRlcGrn7k1YwI Sdac1Dd3bUxRU3XLF/tVKeDjAsU55qu7el7qkd7RdhPjQ1IYV6GIzJPANcaREzv1 m6DBkkTAgkqvBVAQTFbOWLkLYL8KGXYTSjp14ZxB0SH8wrDKaZ/Hb0ASHlDYO7J8 lgjgR1fjfj13IlyjyRLlSeZiXmvHgi1W3NBLwp6nR2V1uwQ+VB7IIkjg+TJ3EN3x wMt1xCmqX9wqsfUgjR5wHJMFNu1maAgdMRUTSWDj0g1P4A4Dvvq1zQJUPtRViZsM 7NzgyrEqWd9gXHAxbP/82eM8QYbzflXEwtz5YFLDhFnXx1sQfE911pE3fklYMnEX SnyslYhK76Xg+E59Q6sGgKYnWyJSPIr88/KouTYKdqbywmg3duEM8a0tp/lLte6o nuA/HI83+sGrSnxGF8cZy8GOY6+MepzUEwX8uQlYSE9RNu/owqF3pCRpyJ6E6udz QvlSzQy6a8d8CewUQ6G8cQETAoSadaEsPdZzaEAj/6jgThTcZKnMnUFx3G/6VM2c ykHHoe6dBLlmesiqirXOiT99Hel09yvlI07H82kmT2JmRcqgUak= =M4IK -----END PGP SIGNATURE-----

3 4

Exit relays and DNS privacy
by foreststack＠dmc.chat 22 Oct '25

22 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I run several exit relays. I'm trying to keep them in diverse locations (South Africa, Moldova, USA, and Canada so far, with none in any AS that hosts more than 1% of network bandwidth). I'm using Unbound as a local recursive DNS resolver so I don't have to trust 3rd parties with the DNS queries. But I can't run Unbound on the same IP that exit traffic goes through because some nameservers blacklist Tor, so I use a second IP. With the price of IPv4s these days, this can inflate the cost of a budget VPS by a significant percentage of its original cost. Right now, Unbound is set up with prefetching and key prefetching enabled, DNSSEC validation enabled, QNAME minimization, a large cache and negative cache, and a local copy of the root zone (RFC 8806). Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT? The way I see it, that has a few pros: * By saving on IPv4 costs, I can run more relays. * An attacker who can monitor the outgoing DNS traffic doesn't know which relay it is coming from, as all relay DNS queries are mixed. * By sharing a single cache, there will be more cache hits and less need to talk to nameservers and expose queries to them. In other words, a nameserver would only know "someone on one of forest's relays looked up this site" rather than "someone on this particular relay looked up this site". But I can see there being a few cons as well: * By sharing a single cache, "timeless timing attacks" may become worse because a single lookup will prime the cache of all of my relays. * Due to their diverse geographical nature, some exits will have sub- optimal routes to the "master" resolver, which increases latency and allows more entities to know when and how many lookups my servers are making (although not what is being looked up, because of DoT). So what should I do? Run a local recursive resolver on each exit? Set up my own upstream resolver and point all my exits to it? Try to use the ISP's resolver and hope that they configure it well? Use some privacy- friendly upstream resolver like dot.sb? Use a DNS resolver hosted by a major exit operator, as suggested by Nothing To Hide in his blog post https://nothingtohide.nl/blog/improving-dns-privacy-on-tor-exit-relays/? I would like advice on the best solution here. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj3/7UACgkQBh18rEKN 1gtA5RAAj7k0/SbG/ki9uQCAG4MjxQAZU8nfjuIaVet7PRCpiLoH8obBSM6m7Gve Qb+AV+uOl3IwjUwu914opEZmSolZXRF2CJ4mX+dfZlbigRHqf0jCiBwOVChCMeDR lGGrFICZvH+t2Sy3totmlcWD57aHXkDux/0eNHj0c5VmfOQKiehSqF0IlK6xI3KC ozNzBaYjjdYdtsQetpeQ0ZEgtv/xU4a+DqiLh5MApCiyt0lP88nTUTuQ8tu1qL3j ijLoac2/ZXG2nlMrKkIB7qNDG1r5CsIb6BdJM/hyfNr1d23VqJfrlILYJFXi3ZAd GurC4tGb/3m2BqWEgzNu/zT/xZ99Ky5zSK+oJDKCeQ8OLaP1IvgviMB0yXLLozB9 NlJweJMn3c1mJ9TxvG1zWbrABee847bizb0ncwkv3ikrownWaSRW5n4v1SXHv/lO yLYjrNI7KJfqvgECgtYni5n4DBzW98pNkFrD3sBxtz0BUtngC6lXjN1ru9l4m5sW EiMS7ifAOnCTN8g8ipocBihYoNvsESmbjzUka63nrnqnvmG3tZB5oIR+WpvXnU3o hxxmlXfjAgmBNf4kuzlAfBRenFf0HkfE9y//YOmCJOgiZzuV6Tv040kkdUKtXbbS F4ZShpS04UvpniCKSBa3mn8Ft33GR01mRvgzRZ2dXv3heqqWlmo= =wsTY -----END PGP SIGNATURE-----

4 4

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 22 Oct '25

22 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Don't forget to enable DNS over TLS! Of course. :) For my local resolvers, it's not possible of course, but it is DNSSEC- validating. If I use any kind of centralized upstream resolver, whether I operate it or not, I'll only use DoT/DoH/DoQ. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj41AcACgkQBh18rEKN 1gtybw/8CPyLiyhSzl5Bdze4kcO6/EvZlrZAh7oJTdkHALYdzItPs9qGN/OGTHzh mUD2TOqQ4sAIPeuq+n5Xs47zGefVjPt2aVpzJ7yKfzsrS6CQA8VtJrtAsuZIdGxg qjAgis87rLCH2t2x+xfArx65txfp6HhWkzLIUWhbwEDM6PLFTNSi5WVm0BCNwXOt 8pNYfzqlil1HhGjghlnA/B47VAvSnGlozUUFF6yVEoCVglKrRgFCdx24auj2p/Hf /87hIfeZ+UeMSKoRcwQ8JoZeFuDDs7WxdbJh3qFc9T+2hdb77CXciYaVO3+bJR3G IfkZPqKKCNdm982TU2wzy+wDghcfrs6VObk5m4GJoWbltOxSmyX3+Ld5ycDMtRQR EBiSdGM7+QCO82b/zNcCWIOD73ZiDkpe3d3poRAJd0/Bv8EvKsXv2hEhPGE+0eRe NnDwYGLJhwo/sWYeHC5Yr/iHFWr8aq87HnvxaF4GNsrpNlcs+Dnx9UFmLa+Jn41A E8OSZMB9WXmnVQvptrVUg1yx9mo1KloQSq+EhbF5nD7VbFEmJSz+MIg7p4xbMl0L pDg2qt2i9Xl9wp8DQVo+KjO1u05jMzmny93xSkaS2tyDndv0O2eaNzjnf4+GLjsA Pnum5/VRD2EOw1YdIlQ58ENhQDLSlbQXdU4/HwDziutmFlWtuK0= =ct/a -----END PGP SIGNATURE-----

1 0

Relay Search page is showing extremely low BW speed
by am 22 Oct '25

22 Oct '25

Hey there, My VPS is dedicated to running a Tor relay server, so the performance should be good. However, your Relay Search page (metrics.torproject.org) now says the speed is only just "XXX KiB/s"! (X is a number) This should not be true. I ran the `speedtest --secure --server XYZ` on the server in question, and it returns: Using server A Download: 98.34 Mbit/s Upload: 120.44 Mbit/s Using server B Download: 88.81 Mbit/s Upload: 104.86 Mbit/s Using server C Download: 94.34 Mbit/s Upload: 103.05 Mbit/s I also checked the firewall configuration, and it did not limit anything. Are you sure your network measurement server is not overloaded? How about teaming up with speedtest servers to measure real network value? So the questions are: Q1. Where are you measuring this from? Q2. If the Advertised BW is just this low, doesn't my Tor relay won't be used at all?

2 1

Re: tor-relays Digest, Vol 177, Issue 6
by Isaac Grover, Aileron I.T. 15 Oct '25

15 Oct '25

Good morning Brian, The bank may not be using these miseducated blocklist services, but their banking platform certainly might be. There's nothing you can do if the blocklist is blocking your IP address or even an IP block from your ISP. Best you can do is request a new IP address from your ISP, either by contacting their support or powering down your modem and hope it grabs a new IP address when it comes back online. On the other hand, if your specific IP address was being targeted, then if your ISP offers IP address blocks, then get a block and separate your relay from your main network using IP routing on your firewall. Make your day great, Isaac -----Original Message----- From: Brian Henderson <bhenderson001(a)yahoo.co.uk> Hi, first time using this group so I hope I am not braking any rules. I wanted to ask others if they have noticed themselves getting blocked from certain sites (such as banks) because they are running a tor relay? I have checked my ip on various lists and it seems two rarely used lists have a ban on a group of numbers from my isp, but not my number specifically. I have been using my bank for years from this connection, now i seem to be blocked and it coincides with starting to run a tor and i2p relays. I have tried to access the site from different software but it just hangs. The bank claim they are not blocking me. Anyone else had this type of problem? Brian.

1 0

relayor v25.1.0 is released
by nusenu 14 Oct '25

14 Oct '25

Hi, relayor v25.1.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v25.1.0 relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes: * Debian 13 is supported (please upgrade your Debian 12 relays because we plan to remove support for Debian 12 / Debian oldstable) * FreeBSD 14.3 is supported * increase minimal required ansible version from 2.16.14 to 2.18.1 **Note on upgrading from previous relayor versions** when managing Debian/Ubuntu relays A manual step is required when upgrading from previous versions on Debian/Ubuntu relays. To avoid conflicting apt sources make sure to move this file on your Debian/Ubuntu relays directly before running ansible-relayor v25.1.0 for the first time. You can use this command to move the file into your home: sudo mv -i /etc/apt/sources.list.d/deb_torproject_org_torproject_org.list ~ Make sure you did not edit the content of this file before. kind regards, nusenu -- https://nusenu.github.io

1 0

[Proposal] Tor exit lifecycle
by gus 14 Oct '25

14 Oct '25

Dear relay operators, We've drafted a new proposal for the relay operator community. The proposal introduces a lifecycle for Tor exit relays, inspired by the existing lifecycle used for Guard and HSDir flags. The main goal is to make it harder for attackers to quickly deploy malicious exit relays. Your feedback is welcome! You can read and comment on it here: https://gitlab.torproject.org/tpo/community/policies/-/issues/32. Alternatively, you can read the full text below. Gus ``` Filename: 102-tor-exit-lifecycle.md Title: Tor Exit lifecycle Author: Gus - gus at torproject.org, GeKo - gk at torproject.org, Hiro - hiro at torproject.org Created: 2025-10-14 Status: Draft ``` ## Overview Tor exit relays are maintained by volunteers and used to leave the Tor network and access websites and other online services. This proposal introduces a lifecycle for Tor exit relays, inspired by the lifecycle already used for non-exit relays to acquire particular flags, such as the Guard[1] and HSDir[2] flags. The main goal of this proposal is to make it harder for attackers to quickly deploy malicious exit relays and exploit Tor users. The proposed lifecycle adds a staging phase for new relays configured as exit relays. This is a period during which those relays are only functioning as non-exit relays. Afterwards, they become eligible for the Exit flag and can then be used as exit relays as intended. This exit relay lifecycle should raise the operational costs for malicious actors, enable earlier detection of bad relays[3], and provide more protection against Sybil attacks. ## Motivation Currently, because Tor is an open and public network, any relay operator can set up a new exit relay and, after a brief warm-up period, begin handling real user traffic. Malicious actors have exploited this openness to launch man-in-the-middle (MITM)[4][5] attacks, leading to a continuous "whack-a-mole" situation for the Network Health Team and the Directory Authorities: while attackers can often be blocked before causing major harm, significant human resources are required to keep up with them. As a small non-profit, it is essential for the Tor Project to focus its limited resources on mission-critical tasks. By implementing mitigations that force adversaries to invest more time and effort or make their attacks faster and easier to detect, we create a more favorable scenario for the Tor Project and its users. To help with that, a staged lifecycle for exit relays will: - Slow down the deployment speed of malicious exit relays as they will need to go through a staging phase. - Give time for analysis and automatic or proactive scanning before an exit relay sees and can exploit any outgoing user traffic. ## Proposal New relays configured as exit relays must complete a staging phase of 4 days (configurable) before becoming eligible for the Exit flag. The staging phase should be long enough to deter opportunistic abuse, but short enough not to discourage legitimate relay operators. ### Security implications The proposed change does not harm user anonymity or security. By reducing the number of new, untrusted exit relays on the Tor network, it improves safety for Tor users and disincentivizes short-lived "throwaway" malicious exit relays. ## Implementation considerations The exit relay lifecycle could be implemented with the help of Tor configuration options or consensus parameters, so that Directory Authorities can tune the staging length without a tor release, or disable the feature temporarily in unusual capacity situations. The exact code and format details will be specified in a follow-up torspec proposal (and then implemented in tor/arti). Note that the technical implementation may have slight changes to this proposal. ### Participation and Communication Once the exit lifecycle is implemented in a torspec proposal, a communication strategy will take place to inform and support relay operators. This strategy may include, but is not limited to, the following actions: - Update the [Tor Relay Operator documentation](https://community.torproject.org/relay) to include an explanation of the new exit relay lifecycle. - Display a banner on Tor Metrics Relay Search for new exit relays, directing users to the exit lifecycle proposal or relevant documentation. - Inform the relay operator community on their communication channels such as the tor-relays mailing list, blog post, and the Tor Forum. - Document new behavior resulted of the exit lifecycle, for example, if an exit relay drops of the consensus for a period, they will lose their exit flag and will need to restart the lifecycle described on this document. For the implementation discussion, see: https://gitlab.torproject.org/tpo/network-health/team/-/issues/220. ## Notes [1] Tor Guard specification: https://spec.torproject.org/guard-spec/index.html \ [2] HSDIR https://spec.torproject.org/tor-spec/subprotocol-versioning.html?highlight=… \ [3] Criteria for bad relays: https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-… \ [4] Also known as a monster-in-the-middle, machine-in-the-middle, meddler-in-the-middle, manipulator-in-the-middle, person-in-the-middle (PITM), or adversary-in-the-middle (AITM) attack. \ [5] https://blog.torproject.org/bad-exit-relays-may-june-2020/ -- The Tor Project Community Team Lead

1 0