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
