Hacker News new | ask | show | jobs
by bnl_umass 269 days ago
There is a known solution.

Did you know that the Tor Project allows exit nodes to filter based on the clear internet IP. So filtering is ok.

However, if a relay refuses to service an onion site directory look up, it will be banned by the Directory Authority. They could allow this today. But they don’t. That’s the simple solution. No surveillance. Not back door. No less privacy for everyone else.

edit: This is easy to confirm. I’m not asking anyone to trust me.

3 comments

Exit nodes are not used for onion services. From https://onionservices.torproject.org/technology/properties/:

> For the Tor network, Onion Services can alleviate the load on exit nodes, since it's connections don't need to reach the exits.

Also:

> Directory Authority.

"These authorities are operated by trusted organizations or individuals with a strong commitment to the principles of privacy, security, and network neutrality."

Emphasis on neutrality... it's not the job of network operators to police the sites people can and can't access, this is exactly why many people use Tor in the first place.

> They could allow this today. But they don’t.

Speaking for onion services... no, they cannot, because the entire design of the tor network prevents this in the first place. No relay in the circuit knows the final destination because it is encrypted multiple times (like an onion) and each hop can only see where it needs to go next, not what the destination is.

I think the point is that exit node operators can filter traffic they don’t want to support. Guard and middle nodes are not given the same choice; they apparently must support all traffic or get booted. Why can’t other nodes have freedom to decide how they want to participate?
> Why can’t other nodes have freedom to decide how they want to participate?

Because the network was explicitly designed to not allow this... otherwise it becomes subject to censorship, which is one of the main goals they try to prevent.

The (onion) address itself is never transmitted in plaintext through the Tor network... when you access an onion site, your Tor client encrypts the traffic multiple times, literally like an onion. No relay in the circuit knows the final destination.

It is absolutely a design decision. I don’t understand though how allowing exit nodes to filter (by port and IP) doesn’t permit censorship but allowing internal nodes to not complete connections to onion sites does. I do understand that early nodes on the path are unaware of what the traffic but it seems pretty straightforward to allow nodes to not become rendezvous points for onion sites.
You are welcome to fork Tor and create a version that uses this approach, but good luck getting people to use it.

Conversely, even if the official project implemented an onion blacklist, a fork would quickly appear to remove it. And node operators would likely prefer that one.

Anyone with any sense understands that introducing a node blacklist creates the capability to expand the use of that blacklist in the interest of political and/or military censorship. The Tor project, Tor devs, and node operators are adamantly opposed to any such censorship capabilities. Therefore it will not happen, period.

That’s not at all what I proposed. Not even close.

Edit: on second look I can see how you could think it was. I’m just proposing that if you run a node you be allowed to not become a rendezvous point for onion sites.

>Did you know that the Tor Project allows exit nodes to filter based on the clear internet IP. So filtering is ok.

That's simply not true. Exit operators who intentionally block websites are flagged as bad relays.

https://community.torproject.org/policies/relays/expectation... https://gitlab.torproject.org/tpo/network-health/team/-/wiki...

I think that is referring to the node exit policy, which explicitly allows particular ports and IP addresses to be blocked.

https://support.torproject.org/relay-operators/exit-policies...

The documents you referred to just say you need to honor your own exit policy.

Your assumptions are based on faulty understanding of how tor works.
I understand well how it works. I agree this is not possible today’s code base but that limitation is due to a design choice. It’s due to a policy decision that the privacy of children who have been sexually exploited is not as important as the privacy of others (including the privacy of people who sexually exploit children). It’s not a technical limitation. It’s a flaw.

Specifically, it would be easy to add code to hsdir functionality to deny requests for onion sites that are known to be related to csam. Those sites could be announced by the DAs as part of the consensus file, for example. The Tor Project currently lets exit nodes filter by IP address as long as they announce that in their config; this new functionality is of the same kind in the abstract. This change would not be a backdoor. It’s not going to weaken the privacy of anyone using Tor.

The current setup is an extremist position that children who have been abused are not deserving of privacy. It’s a position that all information deserves to be free even if that information is very clearly harmful to others and has no positive benefit to society. One can have that opinion but you won’t find many (outside of this thread) that agree.