www.educatedguesswork.org) to a numeric IP address
(e.g,, 69.163.249.211). This mapping is generally done
via the Domain
Name System (DNS), a global distributed database. The thing
you need to know about the security of the DNS is that it doesn't
have much: records are transmitted without any cryptographic
protection, either for confidentiality or integrity. The
official IETF security mechanism, DNSSEC is based on digital signatures
and so offers integrity, but not confidentiality, and in an any case has
seen extremely limited deployment.
Recently, OpenDNS rolled out DNSCrypt,
which provides both encrypted and authenticated communications between your machine
and a DNSCrypt-enabled resolver such as the one operated by OpenDNS. OpenDNS is
based on DJB's DNSCurve and I've talked about comparisons between DNSSEC and DNSCurve before,
but what's interesting here is that OpenDNS is really pushing the confidentiality
angle:
In the same way the SSL turns HTTP web traffic into HTTPS encrypted Web traffic, DNSCrypt turns regular DNS traffic into encrypted DNS traffic that is secure from eavesdropping and man-in-the-middle attacks. It doesn't require any changes to domain names or how they work, it simply provides a method for securely encrypting communication between our customers and our DNS servers in our data centers. We know that claims alone don't work in the security world, however, so we've opened up the source to our DNSCrypt code base and it's available on GitHub.DNSCrypt has the potential to be the most impactful advancement in Internet security since SSL, significantly improving every single Internet user's online security and privacy.
Unfortunately, I don't think this argument really holds up under examination. Remember that DNS is mostly used to map names to IP addresses. Once you have the IP address, you need to actually do something with it, and generally that something is to connect to the IP address in question, which tends to leak a lot of the information you encrypted.
Consider the (target) case where we have DNSCrypt between your local
stub resolver and some recursive resolver somewhere on the
Internet. The class of attackers this protects against is those which
have access to traffic on the wire between you and the resolver.
Now, if I type http://www.educatedguesswork.org/ into
my browser, what happens is that the browser tries to
resolve www.educatedguesswork.org, and
what the attacker principally learns is (1) the hostname I am
querying for and (2) the IP address(es) that were returned.
The next thing that happens, however, is that my browser forms
a TCP connection to the target host and sends something like this:
GET / HTTP/1.1 Host: www.educatedguesswork.org Connection: keep-alive Cache-Control: max-age=0 ...
Obviously, each IP packet contains the IP address of the target
the Host header contains the target host name, so
any attacker on the wire learns both. And as
this information is generally sent over the same access network
as the DNS request, the attacker learns all the information
they would have had if they had been able to observe my DNS query.
[Technical note: when Tor
is configured
properly, DNS requests are routed over Tor, rather than over the
local network. If that's not true, you have some rather more serious
problems to worry about than DNS confidentiality.]
"You idiot," I can hear you saying, "if you wanted confidentiality you
should have used SSL/TLS." That's true, of course, but SSL/TLS barely
improves the situation. Modern browsers provide the target host name
of the server in question in the clear in the TLS handshake using
the Server
Name Indication (SNI) extension. (You can see if your browser
does it here), so the attacker
learns exactly the same information whether you are using SSL/TLS or
not. Even if your browser doesn't provide SNI, the hostname
of the server is generally in the server's certificate. Pretty
much the only time that a useful (to the attacker) hostname isn't
in the certificate is when there are a lot of hosts hidden behind
the same wildcard certificate, such as when your domain is
hosted using Heroku's "piggyback SSL". But this kind of certificate
sharing only works well if your domain is subordinated behind
some master domain (e.g, example-domain.heroku.com),
which isn't really what you want if you're going to offer a serious
service.
This isn't to say that one couldn't design a version of SSL/TLS that didn't leak the target host information quite so aggressively—though it's somewhat harder than it looks—but even if you were to do so, it turns out to be possible to learn a lot about which sites you are visiting via traffic analysis (see, for instance here and here). You could counter this kind of attack as well, of course, but that requires yet more changes to SSL/TLS. This isn't surprising: concealing the target site simply wasn't a design goal for SSL/TLS; everyone just assumed that it would be clear what site you were visiting from the IP address alone (remember that when SSL/TLS was designed, it didn't even support name-based virtual hosting via SNI). I haven't seen much interest in changing this, but unless and until we do, it's hard to see how providing confidentiality for DNS traffic adds much in the way of security.
