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