> > One thing I would really like help with is compiling a list of reasons for > which nodes have been given the BadExit flag. >
Hi John. Here's a couple more past discussions concerning bad exits: JustaNode (ssl mitm?) - http://www.mail-archive.com/or-talk@freehaven.net/msg11540.html spacecowboy (content injection?) - http://www.mail-archive.com/or-talk@freehaven.net/msg10998.html There's currently four relays marked as a bad exit according to http://torstatus.blutmagie.de *capoteATWO* Misconfiguration - http://archives.seul.org/or/relays/Apr-2010/msg00108.html http://torstatus.blutmagie.de/router_detail.php?FP=dd0f0a72a773ed5f2ea298be0dd1177560f97a9a *networkcc958ca* / *netwroke421d2a* Not really sure why... kinda weird since it's not configured to be an exit anyway (Reject */*) http://torstatus.blutmagie.de/router_detail.php?FP=7621f6493a49a4f9da13ff89ca75a08316993a31 http://torstatus.blutmagie.de/router_detail.php?FP=db0e1ce11e3ac37eb4190ffde7653eae9cbdbf20 *PrivacyNow* Misconfiguration (DNS) http://torstatus.blutmagie.de/router_detail.php?FP=cf8e39514ddd90512ebe6498ded006419b0d8f85 Cheers! -Damian On Sun, May 16, 2010 at 9:26 PM, John M. Schanck <jm...@hampshire.edu>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > On Sat, May 15, 2010 at 11:58:44PM -0400, Roger Dingledine wrote: > > 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. :) > > I definitely think both can be pursued in parallel. I've set up a blog > for documenting my progress, > http://anomos.info/~john/gsoc<http://anomos.info/%7Ejohn/gsoc>, > the most > recent post (5/17/2010) is about the goals of SoaT, and the definition > of BadExit. One thing I would really like help with is compiling a > list of reasons for which nodes have been given the BadExit flag. > I've collected information on seven cases where a BadExit flag was > given, or suggested, but I'm sure there are others. > > > > 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) > Had to finish up finals ;-) > > > 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. > > I'm starting to build a list of the attacks SoaT should defend against; > I'm confident that we can be completely public about what those attacks > are, as well as what our defenses are - although I'd like Mike's input > on that. The secret config file you mention is less about obscuring which > tests are being run, and more about not publishing the fingerprintable > characteristics of the scanner (rates at which certain operations occur, > etc). > > > 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. > > Agreed. There's a partial list on the blog now, I'll take comments there > for a few days and then bring the discussion back here to get an idea of > the relative importance of each attack and strategies for conducting the > tests. > > Cheers! > John > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEAREDAAYFAkvwxWkACgkQke2DTaHTnQkZ0gCeOTmal1sGHpnA/oYZBRF3kVUo > ghQAniwE/y5O1WeA01Uk54Nkkjj99ZOE > =mjBs > -----END PGP SIGNATURE----- > *********************************************************************** > To unsubscribe, send an e-mail to majord...@torproject.org with > unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ >
