Re: [tor-talk] Bad Exit Node Control

[Aaron <aagbsn@xxxxxxxx>]

On Sun, Mar 31, 2013 at 4:45 PM, Roc Admin <onionroutor@xxxxxxxxx> wrote:
> 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?

This is a thought I've also had. There are some missing parts (namely,
Tor circuit control) that don't yet exist, but intend to add in the
future. There should be an OONI test template (see ooni/templates) for
tests that need to interact with Tor.

Some other things to address:
* how are exits selected for testing? From an input file? Or Tor consensus?
* how are the output reports formatted? What data is included? Where
are they submitted?
* Who runs the tool? Would it work like the current BwAuth, where a
DirAuth and BwAuth operator pair up, or could anyone report BadExit?

This sounds like a project needing a proposal (see tor-spec.git if
you're not familiar). I'd be happy to collaborate, if anyone is
interested in going this direction.

--Aaron

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