Re: [tor-talk] Bad Exit Node Control

[Andrew F <andrewfriedman101@xxxxxxxxx>]

Aaron, Do you know the answer or where I can find the information?  a doc
file perhaps?

When Tor sends out packets over the Tor network, are they always the same
size?  If not is there a max size?

thanks


On Thu, Apr 11, 2013 at 1:17 PM, Andrew F <andrewfriedman101@xxxxxxxxx>wrote:

> 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