Re: [GSoC] Improving Snakes on a Tor

[Roger Dingledine <arma@xxxxxxx>]

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@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/