[GSoC] Improving Snakes on a Tor

[Damian Johnson]

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]

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

[0] http://archives.seul.org/or/talk/Apr-2010/msg00148.html

On Fri, May 14, 2010 at 3:15 PM, Roger Dingledine <arma at mit.edu> wrote:

> On Sat, May 01, 2010 at 02:55:53PM -0700, Damian Johnson wrote:
> > An easy place to start would be to solicit input on or-talk for a better
> > definition and enumerable attributes we can look for. Some obvious
> starting
> > ones would be ssl stripping, certificate tampering (checking for
> differences
> > like the Perspectives addon [2]), and bad DNS responses. I'd imagine
> Scott
> > Bennett would be glad to jump in with some more ideas. :)
>
> The balance here is between making use of imperfect exit resources that
> people volunteer, and keeping the content you can reach through Tor
> "clean". If we had infinite exit relays, it would be clear that we should
> hunt for any differences and ban all relays that don't behave perfectly.
>
> I think John's starting point, of doing very simple tests and trying to
> reduce false positives, is a good way to go. The goal would be identifying
> exit relays that are *accidentally* broken, for example because their
> ISP or upstream or software AV system messes with the traffic. Detecting
> these can be as simple as fetching an html page with known content, and
> seeing if you get the right content. Then we can focus on doing tests as
> soon as possible when a new exit relay shows up (rather than waiting for
> the relay to get into the consensus, go to clients, see some use, etc),
> and on automating the process of getting the directory authorities to
> change its status.
>
> The next missing steps there are a) how to contact exit relays that are
> accidentally broken so they have a hope of fixing the problem, and b)
> how to let broken exits still be somewhat useful. These aren't problems
> that John needs to tackle (at least not this summer ;), but solving them
> will will make his work more useful.
>
> For "a", it's easy if they set their ContactInfo. Problem is, many exits
> don't set it, or don't set it accurately. We could set a message at the
> directory authorities that their relay gets every time it publishes a
> descriptor, and then have their relay log the message (and/or tell Vidalia
> to pop up a message). We're on our way to supporting that approach,
> but we never finished all the steps. If anybody wants to pick that up,
> please do.
>
> For "b", it could be smart to just remove certain ports from the exit
> policy. We can't change the exit policy in the descriptor clients get
> (because it's self-signed by the relay), but for example in the consensus
> we can say that exiting on port 80 of that relay is bad but the rest of
> the ports are ok. I guess how much energy we put into part b depends on
> how many broken relays we find, and how successful we are at part a.
>
> There is a separate arms race of detecting intentionally broken exits.
> But imo that isn't really an arms race we can win with SoaT. The way
> to do better at that one is to teach users and service providers about
> end-to-end authentication and encryption. Oh, and solve the fact that
> the whole Certificate Authority infrastructure idea is a mess.
>
> --Roger
>
> ***********************************************************************
> 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/20100515/d2e00916/attachment.htm>