On Donnerstag, 20. Juni 2024 02:00:18 CEST tor@nullvoid.me wrote:

I do not think that asking to remove the complete non-exit list to be valuable to the security of the global internet.

However, this non-exit list should not be activated automatically or with one- click. There is no reason to block non-exit relays.

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.

Ransomware links are usually opened from emails and Tor is not running on company computers. Users cannot install anything either. How are they supposed to reach the hidden services?

Users can bypass this blocklist with bridges from their private devices. There are private things that are none of the sysadmins' business and for this some users use Tor or VPN.

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.

You are right that a dedicated IP for a Tor relay would be better. On the other hand, we want more relays at universities.

Many users cannot reach the mirror Halifax = ftp2.de.debian.org

We should perhaps consider at the relay meeting on Saturday whether several relay operators or the Tor Project could write to dan.me.uk. He shouldn't make it so easy to activate the non-exit list. For example, UniFi devices are often installed by inexperienced admins. They simply click on all the block lists without knowing what they are.

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.