doc/spec/proposals/129-reject-plaintext-ports.txt

   1 Filename: 129-reject-plaintext-ports.txt
   2 Title: Block Insecure Protocols by Default
   3 Version: $Revision$
   4 Last-Modified: $Date$
   5 Author: Kevin Bauer & Damon McCoy
   6 Created: 2008-01-15
   7 Status: Closed
   8 Implemented-In: 0.2.0.x
   9
  10 Overview:
  11
  12   Below is a proposal to mitigate insecure protocol use over Tor.
  13
  14   This document 1) demonstrates the extent to which insecure protocols are
  15   currently used within the Tor network, and 2) proposes a simple solution
  16   to prevent users from unknowingly using these insecure protocols. By
  17   insecure, we consider protocols that explicitly leak sensitive user names
  18   and/or passwords, such as POP, IMAP, Telnet, and FTP.
  19
  20 Motivation:
  21
  22   As part of a general study of Tor use in 2006/2007 [1], we attempted to
  23   understand what types of protocols are used over Tor. While we observed a
  24   enormous volume of Web and Peer-to-peer traffic, we were surprised by the
  25   number of insecure protocols that were used over Tor. For example, over an
  26   8 day observation period, we observed the following number of connections
  27   over insecure protocols:
  28
  29     POP and IMAP:10,326 connections
  30     Telnet: 8,401 connections
  31     FTP: 3,788 connections
  32
  33   Each of the above listed protocols exchange user name and password
  34   information in plain-text. As an upper bound, we could have observed
  35   22,515 user names and passwords. This observation echos the reports of
  36   a Tor router logging and posting e-mail passwords in August 2007 [2]. The
  37   response from the Tor community has been to further educate users
  38   about the dangers of using insecure protocols over Tor. However, we
  39   recently repeated our Tor usage study from last year and noticed that the
  40   trend in insecure protocol use has not declined. Therefore, we propose that
  41   additional steps be taken to protect naive Tor users from inadvertently
  42   exposing their identities (and even passwords) over Tor.
  43
  44 Security Implications:
  45
  46   This proposal is intended to improve Tor's security by limiting the
  47   use of insecure protocols.
  48
  49   Roger added: By adding these warnings for only some of the risky
  50   behavior, users may do other risky behavior, not get a warning, and
  51   believe that it is therefore safe. But overall, I think it's better
  52   to warn for some of it than to warn for none of it.
  53
  54 Specification:
  55
  56   As an initial step towards mitigating the use of the above-mentioned
  57   insecure protocols, we propose that the default ports for each respective
  58   insecure service be blocked at the Tor client's socks proxy. These default
  59   ports include:
  60
  61     23 - Telnet
  62     109 - POP2
  63     110 - POP3
  64     143 - IMAP
  65
  66   Notice that FTP is not included in the proposed list of ports to block. This
  67   is because FTP is often used anonymously, i.e., without any identifying
  68   user name or password.
  69
  70   This blocking scheme can be implemented as a set of flags in the client's
  71   torrc configuration file:
  72
  73     BlockInsecureProtocols 0|1
  74     WarnInsecureProtocols 0|1
  75
  76   When the warning flag is activated, a message should be displayed to
  77   the user similar to the message given when Tor's socks proxy is given an IP
  78   address rather than resolving a host name.
  79
  80   We recommend that the default torrc configuration file block insecure
  81   protocols and provide a warning to the user to explain the behavior.
  82
  83   Finally, there are many popular web pages that do not offer secure
  84   login features, such as MySpace, and it would be prudent to provide
  85   additional rules to Privoxy to attempt to protect users from unknowingly
  86   submitting their login credentials in plain-text.
  87
  88 Compatibility:
  89
  90   None, as the proposed changes are to be implemented in the client.
  91
  92 References:
  93
  94   [1] Shining Light in Dark Places: A Study of Anonymous Network Usage.
  95       University of Colorado Technical Report CU-CS-1032-07. August 2007.
  96
  97   [2] Rogue Nodes Turn Tor Anonymizer Into Eavesdropper's Paradise.
  98       http://www.wired.com/politics/security/news/2007/09/embassy_hacks.
  99       Wired. September 10, 2007.
 100
 101 Implementation:
 102
 103   Roger added this feature in
 104   http://archives.seul.org/or/cvs/Jan-2008/msg00182.html
 105   He also added a status event for Vidalia to recognize attempts to use
 106   vulnerable-plaintext ports, so it can help the user understand what's
 107   going on and how to fix it.
 108
 109 Next steps:
 110
 111   a) Vidalia should learn to recognize this controller status event,
 112   so we don't leave users out in the cold when we enable this feature.
 113
 114   b) We should decide which ports to reject by default. The current
 115   consensus is 23,109,110,143 -- the same set that we warn for now.
 116