Re: [tor-talk] Bad Exit Node Control

[Roc Admin <onionroutor@xxxxxxxxx>]

I took another look at the OONI project. Although it's oriented towards
ISPs etc, isn't this almost exactly what's needed - or at least a start?
The tests for many of the items that Mike Perry identified in the spec are
already there.

https://gitweb.torproject.org/ooni-probe.git/blob/16ec7a88d426b30a7bd604e97e6b5d7225b9bb91:/README.md

Thoughts?

ROC


On Sun, Mar 31, 2013 at 11:12 AM, Aaron <aagbsn@xxxxxxxx> wrote:

> 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
>
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk