On Fri, Aug 18, 2006 at 07:19:58PM -0500, Mike Perry wrote: > I'd like to also add that it is possible for rogue Tor servers to go > beyond simply evesdropping on traffic. On one occasion I recieved a > corrupt .exe file via Tor.. It appeared to be just noise, but it woke > me up to the possibility that it is quite feasible that Tor exit nodes > can do all sorts of things to traffic: modifiying .exes, injecting > browser/media format exploits, etc etc.
Correct. Woe is the day when a malicious Tor exit node also has a stolen or purchased copy of a trusted CA's key. But you're right, chaos can be had without even that extreme. This is why Tor's packages (and other security packages) come with gpg signatures. The Internet can be a scary place. And Tor users need to be even more aware of this fact than ordinary Internet users. Part of what we need to do is educate the world about all the security issues with being an ordinary user on the Internet. (I don't think Tor introduces any new attacks -- after all, here I am using my open wireless to get to my shared cablemodem in my apartment in Cambridge, and I'd better be aware of all sorts of possible attacks -- but it does change which attacks you can expect to encounter.) The next thing we need to do is continue to work on interfaces and usability for end-user applications like Firefox. What does that lock mean really? If I do (or don't) see the lock, what should I trust? How can we make use of the plethora of anti-phishing schemes currently under research? And lastly, there's the issue of advocacy for authentication, integrity, and confidentiality on the Internet in general. Translation: we need to get everybody using SSL for everything. > Since the Tor client scrubbs > logs, it can be difficult to tell which exit server was in fact > responsible, especially if they only target a small percentage of > connections. > It might be nice if Vidalia had an option to retain some connection > history in-memory only for a period of time on the order of 10s of > minutes for the purposes of monitoring for malicious/censored exit > nodes. Might be that Blossom is useful for you here (with a few tweaks). Or see http://archives.seul.org/or/talk/Jul-2006/msg00040.html for more general options. It's tricky to automate this idea and make it usable because you'd also have to remember which application connection was involved, since several different exit nodes can be active at the same time, for example if they have different exit policies. And that's not something that is simple to do and still be as safe. --Roger
