<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">One thing I would really like help with is compiling a list of reasons for which nodes have been given the BadExit flag.<br>
</blockquote><br>Hi John. Here's a couple more past discussions concerning bad exits:<br>JustaNode (ssl mitm?) - <a href="http://www.mail-archive.com/or-talk@freehaven.net/msg11540.html">http://www.mail-archive.com/or-talk@freehaven.net/msg11540.html</a><br>
spacecowboy (content injection?) - <a href="http://www.mail-archive.com/or-talk@freehaven.net/msg10998.html">http://www.mail-archive.com/or-talk@freehaven.net/msg10998.html</a><br><br>There's currently four relays marked as a bad exit according to <a href="http://torstatus.blutmagie.de">http://torstatus.blutmagie.de</a><br>
<br><u>capoteATWO</u><br>Misconfiguration - <a href="http://archives.seul.org/or/relays/Apr-2010/msg00108.html">http://archives.seul.org/or/relays/Apr-2010/msg00108.html</a><br><a href="http://torstatus.blutmagie.de/router_detail.php?FP=dd0f0a72a773ed5f2ea298be0dd1177560f97a9a">http://torstatus.blutmagie.de/router_detail.php?FP=dd0f0a72a773ed5f2ea298be0dd1177560f97a9a</a><br>
<br><u>networkcc958ca</u> / <u>netwroke421d2a</u><br>Not really sure why... kinda weird since it's not configured to be an exit anyway (Reject */*)<br><a href="http://torstatus.blutmagie.de/router_detail.php?FP=7621f6493a49a4f9da13ff89ca75a08316993a31">http://torstatus.blutmagie.de/router_detail.php?FP=7621f6493a49a4f9da13ff89ca75a08316993a31</a><br>
<a href="http://torstatus.blutmagie.de/router_detail.php?FP=db0e1ce11e3ac37eb4190ffde7653eae9cbdbf20">http://torstatus.blutmagie.de/router_detail.php?FP=db0e1ce11e3ac37eb4190ffde7653eae9cbdbf20</a><br><br><u>PrivacyNow</u><br>
Misconfiguration (DNS)<br><a href="http://torstatus.blutmagie.de/router_detail.php?FP=cf8e39514ddd90512ebe6498ded006419b0d8f85">http://torstatus.blutmagie.de/router_detail.php?FP=cf8e39514ddd90512ebe6498ded006419b0d8f85</a><br>
<br>Cheers! -Damian<br><br><div class="gmail_quote">On Sun, May 16, 2010 at 9:26 PM, John M. Schanck <span dir="ltr"><<a href="mailto:jms07@hampshire.edu">jms07@hampshire.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: RIPEMD160<br>
<div class="im"><br>
On Sat, May 15, 2010 at 11:58:44PM -0400, Roger Dingledine wrote:<br>
> On Sat, May 15, 2010 at 06:37:54PM -0700, Damian Johnson wrote:<br>
> > Hmmm... so we aren't interested in having a clearer definition of what makes<br>
> > up a bad exit? From the following I thought this is something we were<br>
> > interested in John looking into:<br>
> ><br>
> > "On the bright side though, it's looking good that we'll be able to get a<br>
> > google summer of code student to revive Mike Perry's "Snakes on a Tor"<br>
> > project, and hopefully that means we will a) have some automated scans<br>
> > looking for really obviously broken relays, and *b) build a clearer policy<br>
> > about what counts as badexit and what doesn't, so we can react faster<br>
> > next time.*" [0]<br>
><br>
> Good point. I didn't mean to discourage him from working on more than<br>
> one direction at once. I suspect that working on good clean tests<br>
> that don't produce false positives, and setting up the infrastructure<br>
> to automatically launch them and gather results, is something that can<br>
> actually be clearly accomplished and finished; whereas trying to sort out<br>
> the right balance between "subtly not working right" and "still worth<br>
> letting ordinary users exit from" is a rat-hole that may well lead to<br>
> madness plus no useful results. In short, it sounds like both are worth<br>
> pursuing in parallel. :)<br>
<br>
</div>I definitely think both can be pursued in parallel. I've set up a blog<br>
for documenting my progress, <a href="http://anomos.info/%7Ejohn/gsoc" target="_blank">http://anomos.info/~john/gsoc</a>, the most<br>
recent post (5/17/2010) is about the goals of SoaT, and the definition<br>
of BadExit. One thing I would really like help with is compiling a<br>
list of reasons for which nodes have been given the BadExit flag.<br>
I've collected information on seven cases where a BadExit flag was<br>
given, or suggested, but I'm sure there are others.<br>
<div class="im"><br>
> > This strikes me as something very easy he could do to both:<br>
> > 1. start integrating with the community more (all the gsoc students have<br>
> > been very quiet so far, hence I'm trying to encourage him to spark a<br>
> > discussion on or-talk)<br>
</div>Had to finish up finals ;-)<br>
<div class="im">> > 2. it'll provide ideas of things that SoaT can look for later for both<br>
> > misconfigured and malicious exits<br>
> ><br>
> > I agree that we should try and either fix or find safe ways of using bad<br>
> > exits, and that using SoaT to try and protect the network from all the evils<br>
> > exit relays can dish at us is an arms race we'd lose. However, for many of<br>
> > the nastier active attacks like sslstrip I don't see why we should be waving<br>
> > the white flag right away. Cheers! -Damian<br>
><br>
> Yep. Is there a list somewhere of what active attacks SoaT would like<br>
> to defend against, and how to do each of the corresponding tests? I<br>
> remember Mike originally designed SoaT to have a "secret" config file,<br>
> so bad guys couldn't learn what the tests are.<br>
> <a href="https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/README.ExitScanning" target="_blank">https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/README.ExitScanning</a><br>
> <a href="https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/soat_config.py" target="_blank">https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/soat_config.py</a><br>
> While I can see some reasons for doing it that way, that shouldn't stop<br>
> us from documenting whatever we can publically.<br>
> <a href="https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/data/soat/" target="_blank">https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/data/soat/</a><br>
> should give us a few hints about what Mike was thinking.<br>
<br>
</div>I'm starting to build a list of the attacks SoaT should defend against;<br>
I'm confident that we can be completely public about what those attacks<br>
are, as well as what our defenses are - although I'd like Mike's input<br>
on that. The secret config file you mention is less about obscuring which<br>
tests are being run, and more about not publishing the fingerprintable<br>
characteristics of the scanner (rates at which certain operations occur, etc).<br>
<div class="im"><br>
> Once we have that list would be a good time to solicit opinions for<br>
> what's missing from it or whether it's doing tests is a suboptimal way.<br>
<br>
</div>Agreed. There's a partial list on the blog now, I'll take comments there<br>
for a few days and then bring the discussion back here to get an idea of<br>
the relative importance of each attack and strategies for conducting the<br>
tests.<br>
<br>
Cheers!<br>
John<br>
<div class="im">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
</div>iEYEAREDAAYFAkvwxWkACgkQke2DTaHTnQkZ0gCeOTmal1sGHpnA/oYZBRF3kVUo<br>
ghQAniwE/y5O1WeA01Uk54Nkkjj99ZOE<br>
=mjBs<br>
-----END PGP SIGNATURE-----<br>
<div><div></div><div class="h5">***********************************************************************<br>
To unsubscribe, send an e-mail to <a href="mailto:majordomo@torproject.org">majordomo@torproject.org</a> with<br>
unsubscribe or-talk in the body. <a href="http://archives.seul.org/or/talk/" target="_blank">http://archives.seul.org/or/talk/</a><br>
</div></div></blockquote></div><br>