[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Proposal to mitigate insecure protocols over Tor
- To: or-dev@xxxxxxxx
- Subject: Proposal to mitigate insecure protocols over Tor
- From: "Kevin Bauer" <ksbauer@xxxxxxxxx>
- Date: Thu, 17 Jan 2008 12:18:00 -0700
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Thu, 17 Jan 2008 14:18:09 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=XIzxJfhUPXALDsqS6OsqP79P6HVHBFr2byeSNtPktUc=; b=GJlVZQE6imRgBuoQj9PvvDHYZodfK+l4lzKUgE+98Fb05/WBEWx7SCozq5v2yq3dnbC9O4B9nQ8Xmb+iuwiqYoM8OcCzVuH1+e2CfkpkuTf0rlESfKiJldWZkkqY4IhcSbc96ObNgfnUm5pJQ6feRkMTxF1rX1OtOJuHdx1mbU4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DmbhZFsMRb/Iebg8O2xuFbevEwNYub4irqL8rBSOVJbwdFUE8QZ8U9o9oO2NGvKxIhQ1mvzLdREb/48VRqOqKo3U4fvp4Wfhq64tLZXb+Zh+IEfJ99LdHYksMOXgHtV/HitG83Tb7E1SN4g7CAo222TXQeIZzTMYiRfT2NIIDIQ=
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
Below is a proposal to mitigate insecure protocol use over Tor.
Title: Block Insecure Protocols by Default
Author: Kevin Bauer & Damon McCoy
Date: January 15, 2008
Overview:
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:
None. This proposal is intended to improve Tor's security by limiting the
use of insecure protocols.
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.