Re: [tor-talk] Bad Exit Node Control

[Aaron <aagbsn@xxxxxxxx>]

On Sat, Mar 30, 2013 at 4:18 PM, Roc Admin <onionroutor@xxxxxxxxx> wrote:
>> 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.

While it may be an arms race. I don't think it's as bad as you might
think. For starters, there's a lot of low hanging/high reward fruit --
just two volunteers running BadExit scans collaboratively would be a
huge improvement.

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

This isn't likely to work either, as bad exits can wait arbitrary
amount of time after passing any tests before attacking clients. I
think it's preferable that tests are unpredictable, periodic, and
looks as much like a real user as possible.

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