On Mon, Apr 1, 2013 at 10:01 PM, Andrew F <[email protected]> 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 <[email protected]> wrote: > >> On Sun, Mar 31, 2013 at 4:45 PM, Roc Admin <[email protected]> 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 <[email protected]> wrote: >> > >> >> On Sat, Mar 30, 2013 at 4:18 PM, Roc Admin <[email protected]> >> 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 >> >> > [email protected] >> >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >> _______________________________________________ >> >> tor-talk mailing list >> >> [email protected] >> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> >> >> > _______________________________________________ >> > tor-talk mailing list >> > [email protected] >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> _______________________________________________ >> tor-talk mailing list >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >> > _______________________________________________ > tor-talk mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
