1 files changed, 0 insertions, 114 deletions
diff --git a/doc/spec/proposals/129-reject-plaintext-ports.txt b/doc/spec/proposals/129-reject-plaintext-ports.txt
deleted file mode 100644
index 8080ff5b7..000000000
--- a/doc/spec/proposals/129-reject-plaintext-ports.txt
+++ /dev/null
@@ -1,114 +0,0 @@
-Filename: 129-reject-plaintext-ports.txt
-Title: Block Insecure Protocols by Default
-Author: Kevin Bauer & Damon McCoy
-Created: 2008-01-15
-Status: Closed
-Implemented-In: 0.2.0.x
-
-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.
-