Proposal to mitigate insecure protocols over Tor

[Kevin Bauer]

On Jan 17, 2008 1:56 PM, Roger Dingledine <arma at mit.edu> wrote:
> On Thu, Jan 17, 2008 at 12:18:00PM -0700, Kevin Bauer wrote:
> > Title: Block Insecure Protocols by Default
> > Author: Kevin Bauer & Damon McCoy
>
> Hi Kevin,
>
> Thanks for the proposal. I've been pondering something similar
> lately. I've got a few questions below.
>
> >       POP and IMAP:10,326 connections
> >       Telnet: 8,401 connections
> >       FTP: 3,788 connections
>
> Were (many of) these FTP username/password pairs anon-ftp or were they
> actual logins?
>

We restricted our analysis to application protocol identification
only, so we do not have any data on what portion of the ftp traffic
used a username/password pair. I suspect that the majority of the ftp
traffic was anonymous, but I can't provide data to support that.

> >       As an initial step towards mitigating the use of the above-mentioned
> >       insecure protocols, we propose that the default ports for each respective
> >       insecure service be blocked at the Tor client's socks proxy. These default
> >       ports include:
> >
> >         23 - Telnet
> >       109 - POP2
> >       110 - POP3
> >       143 - IMAP
>
> Right, this seems like it's not a crazy idea. I had been pondering
> setting up some Tor controller status events "insecure port used" that
> Vidalia could monitor to inform its user that they had just tried doing
> something dangerous.
>
> >         BlockInsecureProtocols 0|1
> >         WarnInsecureProtocols 0|1
>
> This seems like a fine interface. The status events I mention above
> could still be useful, because if Block is default, there will be a lot
> of confused users unless Vidalia pops up a little something explaining
> that what they just tried may not be a smart move.
>
> (Vidalia could also have the ability to turn off the warnings, for users
> who know they want to do it. But we need to be careful in that regard --
> see the Firefox comments below.)
>
> >       When the warning flag is activated, a message should be displayed to
> >       the user similar to the message given when Tor's socks proxy is given an IP
> >       address rather than resolving a host name.
> >
> >       We recommend that the default torrc configuration file block insecure
> >       protocols and provide a warning to the user to explain the behavior.
>
> Right. I think integration into Vidalia is critical -- few users know
> that Tor even *has* log messages.
>
> >       Finally, there are many popular web pages that do not offer secure
> >       login features, such as MySpace, and it would be prudent to provide
> >       additional rules to Privoxy to attempt to protect users from unknowingly
> >       submitting their login credentials in plain-text.
>
> This is the big issue here. It's all well and good to block pop
> connections. But there are still many ways to give up secrets on an
> unencrypted (or unauthenticated) http channel.
>
> Now, Firefox already has a pop-up warning about this! But users have
> been trained to ignore it.
>
> We're trying to move away from Privoxy towards Polipo, and to put
> the application-level security/privacy smarts into Torbutton-dev
> https://torbutton.torproject.org/dev/ So relying on Privoxy for stuff
> going forward is not a good move. I wonder if there are good ways to
> get Torbutton to help users with http-level issues?
>
> Thanks,
> --Roger
>
>

I agree that insecure http is a significant avenue for information
leakage over Tor. What we are suggesting in this proposal is that we
try to limit the *really stupid* ways that very sensitive information
(user names/passwords) can be accidentally exposed by a naive Tor
user. The protocols that we mentioned not only can lead to anonymity
loss, but also the potential compromise of the accounts when observed
by a malicious exit node.

Adding the appropriate warning messages to Vidalia is a great idea,
even though it's difficult to make users listen to our warnings. At
the very least, if the warnings are present, then the user can decide
to listen to the warning or ignore it. At that point, I would argue
that it's the user's own fault for ignoring our attempt to protect
them. Ultimately, there is no way to force users to be smart about how
they use Tor.

Kevin