mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-04 09:33:33 +01:00
4c81d0d3eb
Mark proposal 129 closed. It was basically implemented as is, and requires no specification changes. svn:r14233
116 lines
4.4 KiB
Plaintext
116 lines
4.4 KiB
Plaintext
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: Closed
|
|
|
|
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.
|
|
|