Thus spake Nick Mathewson (nickm@xxxxxxxxxxxxx): > [tl;dr: We should make client-side DNS cacheing off by default.] > > On Fri, Jul 20, 2012 at 6:27 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev