Add the .txt ending to proposal 129. Mark proposal 123 finished.

svn:r13743

1 files changed, 115 insertions, 0 deletions

diff --git a/proposals/129-reject-plaintext-ports.txt b/proposals/129-reject-plaintext-ports.txt
new file mode 100644
index 0000000..85f8c24
--- /dev/null
+++ b/proposals/129-reject-plaintext-ports.txt
@@ -0,0 +1,115 @@
+Filename: 129-reject-plaintext-ports.txt
+Title: Block Insecure Protocols by Default
+Version: $Revision$
+Last-Modified: $Date$
+Author: Kevin Bauer & Damon McCoy
+Created: 2008-01-15
+Status: Finished
+
+Overview:
+
+  Below is a proposal to mitigate insecure protocol use over Tor.
+
+  This document 1) demonstrates the extent to which insecure protocols are
+  currently used within the Tor network, and 2) proposes a simple solution
+  to prevent users from unknowingly using these insecure protocols. By
+  insecure, we consider protocols that explicitly leak sensitive user names
+  and/or passwords, such as POP, IMAP, Telnet, and FTP.
+
+Motivation:
+
+  As part of a general study of Tor use in 2006/2007 [1], we attempted to
+  understand what types of protocols are used over Tor. While we observed a
+  enormous volume of Web and Peer-to-peer traffic, we were surprised by the
+  number of insecure protocols that were used over Tor. For example, over an
+  8 day observation period, we observed the following number of connections
+  over insecure protocols:
+
+    POP and IMAP:10,326 connections
+    Telnet: 8,401 connections
+    FTP: 3,788 connections
+
+  Each of the above listed protocols exchange user name and password
+  information in plain-text. As an upper bound, we could have observed
+  22,515 user names and passwords. This observation echos the reports of
+  a Tor router logging and posting e-mail passwords in August 2007 [2]. The
+  response from the Tor community has been to further educate users
+  about the dangers of using insecure protocols over Tor. However, we
+  recently repeated our Tor usage study from last year and noticed that the
+  trend in insecure protocol use has not declined. Therefore, we propose that
+  additional steps be taken to protect naive Tor users from inadvertently
+  exposing their identities (and even passwords) over Tor.
+
+Security Implications:
+
+  This proposal is intended to improve Tor's security by limiting the
+  use of insecure protocols.
+
+  Roger added: By adding these warnings for only some of the risky
+  behavior, users may do other risky behavior, not get a warning, and
+  believe that it is therefore safe. But overall, I think it's better
+  to warn for some of it than to warn for none of it.
+
+Specification:
+
+  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
+
+  Notice that FTP is not included in the proposed list of ports to block. This
+  is because FTP is often used anonymously, i.e., without any identifying
+  user name or password.
+
+  This blocking scheme can be implemented as a set of flags in the client's
+  torrc configuration file:
+
+    BlockInsecureProtocols 0|1
+    WarnInsecureProtocols 0|1
+
+  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.
+
+  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.
+
+Compatibility:
+
+  None, as the proposed changes are to be implemented in the client.
+
+References:
+
+  [1] Shining Light in Dark Places: A Study of Anonymous Network Usage.
+      University of Colorado Technical Report CU-CS-1032-07. August 2007.
+
+  [2] Rogue Nodes Turn Tor Anonymizer Into Eavesdropper's Paradise.
+      http://www.wired.com/politics/security/news/2007/09/embassy_hacks.
+      Wired. September 10, 2007.
+
+Implementation:
+
+  Roger added this feature in
+  http://archives.seul.org/or/cvs/Jan-2008/msg00182.html
+  He also added a status event for Vidalia to recognize attempts to use
+  vulnerable-plaintext ports, so it can help the user understand what's
+  going on and how to fix it.
+
+Next steps:
+
+  a) Vidalia should learn to recognize this controller status event,
+  so we don't leave users out in the cold when we enable this feature.
+
+  b) We should decide which ports to reject by default. The current
+  consensus is 23,109,110,143 -- the same set that we warn for now.
+