Proposal to mitigate insecure protocols over Tor

[Kevin Bauer]

As a follow-up to our numbers on insecure protocol usage over Tor, we
developed a method for detecting certain types of exit node logging.
The basic idea behind our method is to 1) set up an authoritative DNS
server for a block of unused IP addresses and 2) send SYN pings to our
unused IPs through exit nodes. If any of the exit nodes perform a
reverse DNS query for the IP, then it shows that they were observing
the traffic. Certain configurations of tcpdump perform reverse DNS
queries in real-time.

After only 1 day of running the detection mechanism described above,
we got DNS hits from one exit router. Upon further inspection, we
found that it only performed reverse DNS queries when it was SYN
pinged through port 110 (the default POP3 port). It seems clear that
this exit router is targeting this "insecure" port, possibly looking
for usernames and passwords.

The router in question is:

Router Name: bytebutlerfour
Fingerprint: 8E17 BA28 629A 8272 8CB3 A642 D282 6DD8 EF56 240E
Contact: Mike <master at desastercenter.com>
IP Address: 84.189.5.52
Hostname: p54BD0534.dip0.t-ipconnect.de
Onion Router Port: 65001
Directory Server Port: None
Country Code: DE
Platform / Version: Tor 0.1.2.19 on Windows Server 2003 Service Pack 1
[domain controller] {enterprise} {terminal services, single user}
{terminal services}
Last Descriptor Published (GMT): 2008-01-31 19:54:04
Current Uptime: 1 Day(s), 1 Hour(s), 29 Minute(s), 46 Second(s)
Bandwidth (Max/Burst/Observed - In Bps): 20480 / 28672 / 23355
Family: $1D3EFD211CB0E230D2223CE72117FDF4665D445E
$1D93DCDFA5987EEC7B279B4583E989D178F91E73
$2FA9A64ADEBBB3A424E7D7891FB63C3AC652E675
$6640ADB2810AA20B616B5599BC422FC1D1394D02

Kevin

On Jan 25, 2008 1:34 AM, Roger Dingledine <arma at mit.edu> wrote:
> On Sun, Jan 20, 2008 at 10:27:57PM -0700, Kevin Bauer wrote:
> > On Jan 19, 2008 11:57 PM, Roger Dingledine <arma at mit.edu> wrote:
> > > So the next question is: reject by default or just warn? I'm inclined to
> > > reject by default, just to counter the number of users who are probably
> > > happily using Tor and have no idea that there's a problem. Even if they
> > > get angry and stop using Tor because it's "broken" now, that's probably
> > > ok for them.
> >
> > For Telnet, IMAP, and POP, I would suggest that the policy be to block
> > by default for the following reason.  During our 8 day observations
> > cited in the initial proposal, the Telnet, IMAP, and POP traffic
> > accounted for around 0.16% of the total connections that were
> > established through our exit node. So we're probably not talking about
> > a large fraction of the protocols that are used over Tor.
>
> Well, you have to remember that we're blocking by port, not blocking
> by protocol.
>
> In chatting with some folks on #tor, they reminded me that an increasing
> number of pop / imap clients are using STARTTLS:
> http://tools.ietf.org/html/rfc2595
> which uses the same ports as the unencrypted varieties.
>
> In an ideal world, we would somehow be able to divine whether the
> protocol going over the port was doing a safe thing or an unsafe thing.
> But I don't much want to write pop and imap proxies, nor to write a pop
> or imap analyzer inside Tor and run it on all the traffic that happens
> to ask for these ports. It still seems like the only real option is
> to just reject them by default, and give Vidalia a good interface to
> reenable ports if you think you're doing it right.
>
> I wonder what proportion of our users are doing this, and if there are
> instructions out there on the 'net somewhere for how to enable encryption
> in standard mail programs?
>
> Of course, if it's optimistic encryption and the mail client doesn't
> know what TLS key to expect from the other side, the encryption may not
> help us much against a hostile exit relay. So the question is not just
> "do they support starttls", but also "do they manage keys intuitively
> and well". And I bet we can all guess the answer to that.
>
> > As far as I know (and perhaps someone can correct me if I'm wrong
> > here), most popular instant messaging services (like AIM, MSN , Yahoo,
> > Jabber, etc.) exchange login credentials securely over SSL/TLS. Thus,
> > in my opinion, they differ from Telnet, IMAP, and POP in this respect.
> > However, they do generally seem to expose a user's screen name in the
> > application header. Thus, they may be unwise to use over Tor for
> > anonymity reasons. Certainly a warning about the risks that are
> > inherent in these instant messaging protocols is prudent, but I think
> > that the information leakage is probably no worse than what is
> > possible over HTTP.
>
> I talked to Ian Goldberg about AIM, and he confirmed that AIM gives at
> least a token effort to not leak your password in the clear. It does
> leak your username, but hopefully this is something that our users can
> comprehend and act appropriately.
>
> --Roger
>
>