From 5375f4bc98a7105dc641b92783b1648e40633a80 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 26 Feb 2008 19:29:40 +0000 Subject: Add the .txt ending to proposal 129. Mark proposal 123 finished. svn:r13743 --- doc/spec/proposals/000-index.txt | 4 +- doc/spec/proposals/123-autonaming.txt | 2 +- doc/spec/proposals/129-reject-plaintext-ports | 115 ---------------------- doc/spec/proposals/129-reject-plaintext-ports.txt | 115 ++++++++++++++++++++++ 4 files changed, 118 insertions(+), 118 deletions(-) delete mode 100644 doc/spec/proposals/129-reject-plaintext-ports create mode 100644 doc/spec/proposals/129-reject-plaintext-ports.txt (limited to 'doc/spec/proposals') diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index 05c37bbb6..4a6585b31 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -45,7 +45,7 @@ Proposals by number: 120 Suicide descriptors when Tor servers stop [OPEN] 121 Hidden Service Authentication [OPEN] 122 Network status entries need a new Unnamed flag [CLOSED] -123 Naming authorities automatically create bindings [OPEN] +123 Naming authorities automatically create bindings [FINISHED] 124 Blocking resistant TLS certificate usage [SUPERSEDED] 125 Behavior for bridge users, bridge relays, and bridge authorities [FINISHED] 126 Getting GeoIP data and publishing usage summaries [FINISHED] @@ -65,7 +65,6 @@ Proposals by status: 117 IPv6 exits 120 Suicide descriptors when Tor servers stop 121 Hidden Service Authentication - 123 Naming authorities automatically create bindings ACCEPTED: NEEDS-RESEARCH: 118 Advertising multiple ORPorts at once @@ -77,6 +76,7 @@ Proposals by status: FINISHED: 105 Version negotiation for the Tor protocol 111 Prioritizing local traffic over relayed traffic + 123 Naming authorities automatically create bindings 125 Behavior for bridge users, bridge relays, and bridge authorities 126 Getting GeoIP data and publishing usage summaries 129 Block Insecure Protocols by Default diff --git a/doc/spec/proposals/123-autonaming.txt b/doc/spec/proposals/123-autonaming.txt index 988b4b96c..00e5fffd7 100644 --- a/doc/spec/proposals/123-autonaming.txt +++ b/doc/spec/proposals/123-autonaming.txt @@ -4,7 +4,7 @@ Version: $Revision$ Last-Modified: $Date$ Author: Peter Palfrader Created: 2007-10-11 -Status: Open +Status: Finished Overview: diff --git a/doc/spec/proposals/129-reject-plaintext-ports b/doc/spec/proposals/129-reject-plaintext-ports deleted file mode 100644 index 85f8c2432..000000000 --- a/doc/spec/proposals/129-reject-plaintext-ports +++ /dev/null @@ -1,115 +0,0 @@ -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. - diff --git a/doc/spec/proposals/129-reject-plaintext-ports.txt b/doc/spec/proposals/129-reject-plaintext-ports.txt new file mode 100644 index 000000000..85f8c2432 --- /dev/null +++ b/doc/spec/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. + -- cgit v1.2.3