Re: [tor-talk] Bad Exit Node Control

[Aaron <aagbsn@xxxxxxxx>]

On Mon, Apr 1, 2013 at 10:01 PM, Andrew F <andrewfriedman101@xxxxxxxxx> wrote:
> Why kick of bad exits?  If you identify an exit that is gathering data or
> manipulating data, then simply take them out of rotation and feed them
> false connections so that they stay on line and wast resources.  Otherwise
> they will shut down and be back up the same day.

BadExit means that relays will not pick this relay as an exit, but it
will still be used as a non-exit relay.

--Aaron
>
> If you can lead them on for a while it will make all tor users safer.
>
>
> On Mon, Apr 1, 2013 at 8:21 PM, Aaron <aagbsn@xxxxxxxx> wrote:
>
>> 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
>>
> _______________________________________________
> 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