[GSoC] Improving Snakes on a Tor

Tue May 18 14:33:14 UTC 2010

>
> 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 <jms07 at 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 majordomo at torproject.org with
> unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20100518/6c703939/attachment.htm>