On Sat, May 15, 2010 at 06:37:54PM -0700, Damian Johnson wrote: > Hmmm... so we aren't interested in having a clearer definition of what makes > up a bad exit? From the following I thought this is something we were > interested in John looking into: > > "On the bright side though, it's looking good that we'll be able to get a > google summer of code student to revive Mike Perry's "Snakes on a Tor" > project, and hopefully that means we will a) have some automated scans > looking for really obviously broken relays, and *b) build a clearer policy > about what counts as badexit and what doesn't, so we can react faster > next time.*" [0]
Good point. I didn't mean to discourage him from working on more than one direction at once. I suspect that working on good clean tests that don't produce false positives, and setting up the infrastructure to automatically launch them and gather results, is something that can actually be clearly accomplished and finished; whereas trying to sort out the right balance between "subtly not working right" and "still worth letting ordinary users exit from" is a rat-hole that may well lead to madness plus no useful results. In short, it sounds like both are worth pursuing in parallel. :) > This strikes me as something very easy he could do to both: > 1. start integrating with the community more (all the gsoc students have > been very quiet so far, hence I'm trying to encourage him to spark a > discussion on or-talk) > 2. it'll provide ideas of things that SoaT can look for later for both > misconfigured and malicious exits > > I agree that we should try and either fix or find safe ways of using bad > exits, and that using SoaT to try and protect the network from all the evils > exit relays can dish at us is an arms race we'd lose. However, for many of > the nastier active attacks like sslstrip I don't see why we should be waving > the white flag right away. Cheers! -Damian Yep. Is there a list somewhere of what active attacks SoaT would like to defend against, and how to do each of the corresponding tests? I remember Mike originally designed SoaT to have a "secret" config file, so bad guys couldn't learn what the tests are. https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/README.ExitScanning https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/soat_config.py While I can see some reasons for doing it that way, that shouldn't stop us from documenting whatever we can publically. https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/data/soat/ should give us a few hints about what Mike was thinking. Once we have that list would be a good time to solicit opinions for what's missing from it or whether it's doing tests is a suboptimal way. --Roger *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
