On Thu, Feb 04, 2021 at 01:20:58AM +0200, s7r wrote:
Indeed the defense is triggered more often than I expected. Very nice.
Btw, a better version of the #2667 patch is now included in all of the current Tor releases: 0.3.5.13, 0.4.3.8, 0.4.4.7, 0.4.5.5-rc.
So if you are still trying out my experiment patch, thank you, but now please stop doing that and move to one of the actual releases. :)
This defense is only implemented at the Exit relay, and it blocks all the relay:ORPort / DirPort combinations that exit knows about according to its version of the consensus?
The design that we decided on was "block relay:ORPort, dirauth:ORPort, and dirauth:DirPort". That is, it doesn't try to block relay:DirPort connections.
We chose that balance because if we'd blocked all relay dirports too, we would have broken relay dirport reachability tests, because the way those tests work is by building an exit circuit and then "exiting" back to the relay's dirport to see if it works.
Ultimately I expect we're going to phase out the concept of a dirport on non-dir-auth relays, since they mostly go unused so it's just yet another thing to maintain that isn't worth it. But now we can do that phase-out completely separate from this topic.
What happens if the abuser has a different valid consensus (newer/older) that has some relays which are not known by the Exit?
If there are edge cases where different sides have different knowledge, then those edge cases will 'get through'. But hopefully they'll be rare, or even if they're not rare, hopefully they will be low-impact.
Or if the abuser uses for re-entry a relay configured with `PublishServerDescriptor 0`? How does it treat bridges?
They are all allowed.
In fact, one of the Tor use cases we're going to break here is people who torify all their traffic (at the network or host level) and then run Tor Browser also. The suggested workaround for them is that if they really need to do this, they should configure their Tor Browser to use a bridge. There will be a bunch of confused users who don't know they're doing this, and don't know why it broke, though.
I've been working on https://gitlab.torproject.org/tpo/core/tor/-/issues/40271 to do a little bit toward that explanation side.
And most important, does this means that an Exit will no longer try to connect to other middle relay? At this moment can't an exit relay (of course with a small probability) be used as a middle or entry? Won't this become a mess if we have 80% of relays Exits and thus used more as 1st or 2nd hops, or in a perfect future where 100% or relays are all exits?
No, exiting is different from extending. Exit relays can still extend to other relays -- this is a part of the Tor protocol that lets a relay make a TLS connection with another relay. The difference is in who the "ends" of that TLS connection are: in the extend case, the ends are the two relays. In the 'exit and reenter' case, one end is the client and the other is the destination relay.
--Roger