Re: [tor-talk] Bad Exit Node Control

[Andrew F <andrewfriedman101@xxxxxxxxx>]

Aaron, thanks for clarification.  I thought we were talking about exit
nodes that are run by people that are sniffing data.
Sure would be nice to identify those exit nodes and deal with them.


On Wed, Apr 3, 2013 at 9:15 PM, Aaron <aagbsn@xxxxxxxx> wrote:

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