[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [GSoC] Improving Snakes on a Tor

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.
While I can see some reasons for doing it that way, that shouldn't stop
us from documenting whatever we can publically.
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.


To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/