[tor-dev] Proposal 205: Remove global client-side DNS caching

[Mike Perry]

Thus spake Nick Mathewson (nickm at freehaven.net):

> [tl;dr: We should make client-side DNS cacheing off by default.]
> 
> On Fri, Jul 20, 2012 at 6:27 PM, Nick Mathewson <nickm at freehaven.net> wrote:
> > Filename: 205-local-dnscache.txt
> > Title: Remove global client-side DNS caching
> > Author: Nick Mathewson
>
> For the original proposal, see
> https://lists.torproject.org/pipermail/tor-dev/2012-July/003817.html
> 
> > 3.1. Why keep client-side DNS caching at all?
> >
> >    A fine question!  I am not sure it actually buys us anything any
> >    longer, since exits also have DNS caching.  Shall we discuss that?
> >    It would sure simplify matters.
> 
> On consideration, I'm actually reasonably sure that eliminating
> client-side DNS cacheing (or at least, turning it off by default) is a
> much better answer than making DNS caches per-circuit.  I've got an
> implementation of my new approach on ticket #7570
> (https://trac.torproject.org/projects/tor/ticket/7570).
> 
> So, why is it okay to disable client-side DNS cacheing entirely?

Nick asked me this in private email:

> Every socks response has an IP address in it.  So when Firefox asks
> for "www.mit.edu" in a SOCKS4a or a SOCKS5 request, Tor gives it
> "18.9.22.169" in the SOCKS response.
>
> Does Firefox cache these values?  That is, in the next SOCKS request
> that Firefox makes for "www.mit.edu", will Firefox ask Tor to connect
> to "www.mit.edu", or to "18.9.22.169"?

Under normal non-SOCKS operation, Firefox does attempt to cache DNS
resolutions for a long period of time (I think on the order of an hour
or more). The reason is because of DNS-based subversions of the
same-origin policy:
https://en.wikipedia.org/wiki/DNS_rebinding
http://www.securityfocus.com/columnists/455

Interestingly, the two main vectors discussed there are not as useful
against Tor, but perhaps worth having on your radar when considering DNS
cache alterations.

Further, the SOCKS behavior for Firefox is quite different than
non-proxied use, perhaps because of the limited vectors for rebinding.
It tends to make very few actual SOCKS4a resolutions, instead perferring
to use direct SOCKS4A hostname connects. Unfortunately, the details of
where and why it actually does decide to do a SOCKS4a resolution are
unknown to me and would require some digging.

This reminds me that I plan to re-audit as much of Firefox's networking
glue as I can for Firefox 17-ESR, to verify it hasn't changed in ways
that allow DNS leaks or proxy bypass. I've created this ticket if you
want to add further DNS-related questions for me to look into once I
start that process:
https://trac.torproject.org/projects/tor/ticket/7248

> I'm asking because of proposal-205 reasons.

Proposal 205 might cause problems for DNS rebinding if the dirty circuit
expiry is small enough for evil JS to simply wait for a fresh circuit to
alter the destination IP of important origins.

However, this vector is eliminated by SSL, and will be mitigated
by making circuit use more closely tied to first party origin (using
SOCKS username+password from Prop171).



-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121218/24842a4b/attachment.pgp>