Re: [tor-talk] Bad Exit Node Control

[Roc Admin <onionroutor@xxxxxxxxx>]

> Does this mean that you're planning to expand the SoaT codebase? Write
> a revised version? If the project is going to be revived then it would
> make sense for it to take advantage of one of our newer controller
> libraries...

Yeah the plan is to do a complete rerwrite of SoaT. That guy was a
beast and almost did its job too well. I talked a little about this on
the tor-dev side but I'm definitely using Stem. I didn't know about
the other project though so thank you. There was also some discussion
about interfacing with Onionoo but now we're talking too far down the
line.

> 2. Even when a bad exit *is* reported our process for flagging it is
> pretty well broken. To be flagged at least two of the three authority
> operators that vote on the BadExit flag need to take manual action.
> All three operators are highly busy people so in practice relays don't
> get flagged without considerable nagging.

Exactly. I think Mike Perry's proposal that Aaron linked to is still
spot on in terms of what we want from a solution. In the deployment
section it notes three phases where the final one is an automatic
communication between the scanning engine and the Tor Network so that
it alerts Directory Authorities. This interface in itself requires
some thought. It's threat model includes accidentally causing a DoS on
all hosts on the network if something goes wrong, or inappropriately
flag a good node, or the fact that knowing how to tool works, a
malicious node could change it's activities to avoid detection.

The other issue that is stuck in my head is that I think exit scanning
is always going to be a losing battle and this is a best-effort game.
I see it in the same way that Android has tried to keep track of
malware on the Play market. It will be days in even the best case
scenario before we find out an exit node is malicious and properly
report them. It's high effort for little return.

In an ideal - not-Tor world - there could be some kind of activation
process for exit nodes that validate configurations and performs
simple checks before they join the network, and contact information is
confirmed (or at least attempted). This assuredly will never happen
for a variety of reasons one of which is that it's a deterrent for
those volunteer operators that we need lots and lots of. I wonder if
this has already been discussed or if it's worth at least documenting
the design decision somewhere. It's valid to say "We won't do this
because of X Y and Z" but I would like to see how the debate would go
against a realistic solution (that has yet to be proposed).

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