[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Proposal to mitigate insecure protocols over Tor
On Sun, Jan 20, 2008 at 10:27:57PM -0700, Kevin Bauer wrote:
> On Jan 19, 2008 11:57 PM, Roger Dingledine <arma@xxxxxxx> wrote:
> > So the next question is: reject by default or just warn? I'm inclined to
> > reject by default, just to counter the number of users who are probably
> > happily using Tor and have no idea that there's a problem. Even if they
> > get angry and stop using Tor because it's "broken" now, that's probably
> > ok for them.
>
> For Telnet, IMAP, and POP, I would suggest that the policy be to block
> by default for the following reason. During our 8 day observations
> cited in the initial proposal, the Telnet, IMAP, and POP traffic
> accounted for around 0.16% of the total connections that were
> established through our exit node. So we're probably not talking about
> a large fraction of the protocols that are used over Tor.
Well, you have to remember that we're blocking by port, not blocking
by protocol.
In chatting with some folks on #tor, they reminded me that an increasing
number of pop / imap clients are using STARTTLS:
http://tools.ietf.org/html/rfc2595
which uses the same ports as the unencrypted varieties.
In an ideal world, we would somehow be able to divine whether the
protocol going over the port was doing a safe thing or an unsafe thing.
But I don't much want to write pop and imap proxies, nor to write a pop
or imap analyzer inside Tor and run it on all the traffic that happens
to ask for these ports. It still seems like the only real option is
to just reject them by default, and give Vidalia a good interface to
reenable ports if you think you're doing it right.
I wonder what proportion of our users are doing this, and if there are
instructions out there on the 'net somewhere for how to enable encryption
in standard mail programs?
Of course, if it's optimistic encryption and the mail client doesn't
know what TLS key to expect from the other side, the encryption may not
help us much against a hostile exit relay. So the question is not just
"do they support starttls", but also "do they manage keys intuitively
and well". And I bet we can all guess the answer to that.
> As far as I know (and perhaps someone can correct me if I'm wrong
> here), most popular instant messaging services (like AIM, MSN , Yahoo,
> Jabber, etc.) exchange login credentials securely over SSL/TLS. Thus,
> in my opinion, they differ from Telnet, IMAP, and POP in this respect.
> However, they do generally seem to expose a user's screen name in the
> application header. Thus, they may be unwise to use over Tor for
> anonymity reasons. Certainly a warning about the risks that are
> inherent in these instant messaging protocols is prudent, but I think
> that the information leakage is probably no worse than what is
> possible over HTTP.
I talked to Ian Goldberg about AIM, and he confirmed that AIM gives at
least a token effort to not leak your password in the clear. It does
leak your username, but hopefully this is something that our users can
comprehend and act appropriately.
--Roger