Re: [tor-relays] Exit relay operators please help test #2667 branch

[Roger Dingledine <arma@xxxxxxxxxxxxxx>]

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

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