Hi Carsten, While I appreciate your effort to make running (non-exit) relays more usable for regular internet usage, and I myself face similar issue. My relay is also my mail host. I sometimes cannot send or receive to certain organizations due to their firewall policies. I do not think that asking to remove the complete non-exit list to be valuable to the security of the global internet. While it is correct that sysadmins should maybe not block traffic just because it's a relay. There is many use cases where they should, most corporation end users do not need access to the Tor network daily, and many ransomware or other malware c2 servers leverage .onion services. By blocking Tor across the network it's a simple way to disarm the malware or prevent data loss to nefarious actors. Secondly, running multiple services from your Tor relay is generally considered bad advice if I understand correctly. Especially critical infrastructure such as mirrors of popular packages. Tor relays should be dedicated hosts with minimal attack surface, we know they are attacked, monitored, and generally attract extra attention. Due to this other services you host on the same server are now at risk of extra surveillance or malicious attacks. Just my two cents, I with DAN list non-exit did not exist either, but it has it's purposes. Regards, tor Carsten Otto:

Hi Dan,

For reference: https://www.dan.me.uk/dnsbl https://www.dan.me.uk/tornodes https://www.dan.me.uk/torlist/?full

First of all, thank you for your tools and other contributions. The mere fact that your DNS blocklists are used by countless vendors should be a compliment in itself, and I'd be happy to have that much impact with my own projects.

As you already state on your own site ("Please think carefully before choosing to use this list for blocking purposes"), your non-exit Tor relay list is a bit unusual. I'm running ftp.halifax.rwth-aachen.de, a major file mirror serving around 30 TByte of data at around 4 GBit/sec (on average). Recently, we added Tor relays on the same IP address, and your list correctly picked this up (137.226.34.46).

Now, I'm writing as this caused quite a lot of mayhem. Several "security" appliance vendors didn't "think carefully" before adding your non-exit list to their devices. Among those are Arbor Prevail, Check Point, Ubiquiti (UniFi) - feel free to search for

"ET TOR Known Tor Relay/Router (Not Exit) Node"

to see the effect of this. In addition to private users making use of such devices, several banks/corporations/institutions started blocking our IP address, causing some frustration with us and their admins, as their Linux/Jenkins/... updates suddenly stopped working. As you might have guessed, changing "security" configurations (even if they may be wrong or questionable) is quite a challenge, and in some cases the (motivated) admins weren't unable to fix this issue on their end.

As you seem to be well aware of what Tor is, what an exit relay does and what a non-exit relay does, would you be willing to retire the non-exit blocklist (at least the part that can be used for automated blocks)? I'd argue that the current setup does more harm than good (assuming you agree that Tor is a good thing in general). I'd be happy to discuss pros and cons, but ultimately that's your decision to make.

Thanks Carsten

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

First of all, thank you for your tools and other contributions. The mere fact that your DNS blocklists are used by countless vendors should be a compliment in itself, and I'd be happy to have that much impact with my own projects. (…) Operating a non-exit Tor relay I face similar issues. I can’t trace them back to this particular blocklist, but with high confidence can tell the challenges we face are from indiscriminately using blacklists. Some of them do contain Tor non-exit relays. So I can do nothing more than I support Carsten’s plea.

Over years no party blocking non-exit relays was able to provide me with a single example of an actual incident, despite continued claims it’s a “malicious traffic from *my* address”. After changes on their end that “malicious traffic” was magically no longer observed. I myself can’t conceive any actual attack coming from a non-exit relay with probability notably higher than from other machines on the internet. The relay itself isn’t designed to connect to machines other than Tor relays, so certainly its intended use doesn’t lead to higher risk. All other factors and attacks should at worst be the same as for the general population. Cheers and thanks for providing the lists, mpan.

I agree, maybe this open letter is better aimed at the security vendors that include DAN's (non-exit) Tor relays list on a blocklist by default, or without warning about potential impact to other legitimate services (universities, libraries, shared hosting providers, hobbyist email, etc) Security vendors are not the only users of such lists. There is much more entities and people, that use them without any intermediaries. Negotiating with every single of them is not only whack-a-moling, but also inefficient compared to addressing the issue at the source.

The issue could be approached in other ways too, but I don’t find them satisfying. It would require things like changing the license, which is an idea I can’t stand behind. It would also demand more effort from Dan, which is unacceptable given he’s offering that free of charge, and likely lead to employing practices I despise.

Once the malware runs it will phone home over Tor to the .onion, from a network perspective this will look like a TCP connection to an entry node. I can see many reasons to maintain a list on known entry nodes to prevent unauthorized applications or users from connection out of a network. Those lists should not be enabled by default to block. That’s a good point, but there are things to note.

Tor entry nodes are publicly known. An organization, that believes they need such a protection, may obtain the list directly from Tor Project. This requires additional effort, yes. But it should require effort. It’s not big, compared to how much it takes to make such a decision in a responsible manner. And it protects against blindly using blocklists without thinking. This is the same reasoning that was driving Polish internet operator (TP) to blanket block servers suspected of running IRC. Not merely connections to IRC, which is questionable on its own, but servers: so one couldn’t e.g. access websites of many FOSS projects. In my college I had to sign additional papers to be able to access some Wikipedia articles. URLs could contain a particular word also found on porn sites, so the college seen this as a risk of students committing the crime of exposing other students to inappropriate content. We see mandating backdoors in encryption, which use the same logic: encryption helps committing crimes. Finally, something probably most close to any Tor user’s heart: a requirement to be fully tracked everywhere or otherwise treated as a second class citizen. Yes, that is also commonly rationalized by protection against attacks. So it’s worth asking, if this is acceptable reasoning.