following on from today's discussion

[Roger Dingledine]

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