On 2016-06-01 03:37 AM, Martin Pitt wrote: > Stéphane Graber [2016-05-31 17:26 -0400]: >> So yes, the random transaction ID sure helps, so long as it's actually >> random and so long as you get a DNS reply reasonably quickly. > > It's reading from /dev/urandom, so pretty much "as random as you can > get". > >> I think your estimate of a minute isn't anywhere near accurate. One >> could pretty easily pre-generate all 32768 packets in pcap format, just >> replace the source address and port once known and then inject the whole >> pcap onto the network much much faster than that. > > No, that doesn't work, as I explained in my other reply. You only have > one shot and then have to wait for the cached entry to time out until > you get another one. I. e. a chance of 1/65536 in say half an hour, > which is much worse than having a chance every few minutes or seconds > if the client does not cache DNS queries.
When the resolver gets the packet with the invalid transaction ID, the query is cancelled, so it doesn't get cached at all. > >>>> 1- a privacy issue. It is trivial for a local user to probe if a site was >>>> visited by another local user. >>> >>> I assume by looking at the time that it takes to get a response? >> >> stgraber@dakara:~$ dig www.ubuntu.com @172.17.20.30 >> www.ubuntu.com. 600 IN A 91.189.89.118 >> >> stgraber@dakara:~$ dig www.ubuntu.com @127.0.0.1 >> www.ubuntu.com. 594 IN A 91.189.89.118 >> >> >> The first query shows you the TTL for the record from the recursive >> server used by the local resolver, here we see it's 600 seconds, the >> second request hits the local cache which returns a TTL of 594 seconds. >> Meaning that the DNS record was accessed by someone on the machine >> within the last 6 seconds. >> >> Do that with some sensitive website and you can know when someone on the >> machine accessed it. >> >> Note that the above wasn't done through resolved. > > Exactly :-) So this is unrelated as dig doesn't use nsswitch and thus > isn't affected by how we configure resolved. > > However, you can still look at the time it takes. When I try this with > a site that I haven't called in ages: > > $ time host www.cnn.com > www.cnn.com is an alias for turner.map.fastly.net. > turner.map.fastly.net has address 185.31.19.73 > real 0m0.170s > > $ time host www.cnn.com > www.cnn.com is an alias for turner.map.fastly.net. > turner.map.fastly.net has address 185.31.19.73 > real 0m0.155s > > $ time host www.cnn.com > www.cnn.com is an alias for turner.map.fastly.net. > turner.map.fastly.net has address 185.31.19.73 > real 0m0.155s > > So there is a measurable time difference when a lookup happens (the > first time) and when it's cached (the two others). > > However: as you demonstrated with dig, you don't necessarily need to > get this information from the local resolver -- you can look at the > TTL at the real DNS servers in /etc/resolv.conf with dig. Assuming the real DNS servers are used by a large number of users, there is a privacy difference in being able to tell if a user on the local machine has visited a particular site versus being able to tell if any one of the large number of users has queried the DNS server. > > So, the current status is: > > 1) I'm not convinced yet [1] that disabling caching helps against > injecting false responses. resolved implements enough of > https://tools.ietf.org/html/rfc5452 to make local attacks > impossible, and remote attacks actually harder than without a > cache. I think hitting a transaction ID collision within a few seconds with a helper machine is plausible. Whether caching is enabled or not is the difference between poisoning your own lookups, or poisoning other user's lookups. > > 2) I acknowledge the timing difference between recently visited and > unvisited addresses, but you can get the same information from > your real DNS server with more precision. The real DNS server only allows you to determine if any of your ISP's users have visited a site. That's quite different than knowing if any local user on a multiuser machine visited a site. > > Thanks! > > Martin > > P.S. This is a really enjoyable and good discussion, thank you! Yes, it's quite interesting! > > [1] Note, I don't claim "it's impossible", I'm just saying that the > current arguments aren't sufficient. > > > Marc. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
