[ranger_danger]

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.

[neutered_knot]

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?

[ranger_danger]

> 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.

[neutered_knot]

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.

[iamnothere]

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.

[neutered_knot]

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.

[iamnothere]

Ah, I misunderstood. In any case, onion traffic is not flagged as such, so nobody but the last hop would even know that onion traffic is being passed. Allowing the last node to kill the whole circuit seems like it would cause routing problems and/or contribute towards deanonymization, as would flagging onion traffic at every step of the journey.