Apr 6, 2018 6 min read

DNS over TLS / DNS over HTTPS - Is it the privacy magic bullet?

Summary of how DNS-over-HTTPS and DNS-over-TLS can help with privacy, but only to a certain point.

DNS over TLS / DNS over HTTPS - Is it the privacy magic bullet?

As many of you may be aware, Cloudflare recently announced their new "privacy-first" consumer DNS service. While most might assume that this will go to great lengths to help ensure that their browsing privacy is maintained, I was a bit dubious, and felt that I was missing something completely. So I decided to do a bit of investigating of what is and isn't possible with this service. How it helps provides privacy, and how far it goes in doing that.

Privacy concerns

One of the privacy related concerns existing today, is that anyone between your computer and the server which you are tying to connect to (be it your ISP, government, an eavesdropper, etc) can see which sites you hit. This is due to the fact that DNS queries happen over plain text. Meaning that anyone who has the ability to view the network traffic, would be able to view these queries.

DNS

We humans are not great at remembering numbers. However this, and more specifically an IP address, is exactly what a computer uses to access a server. As a result domain names were developed to make it easier to remember the "address" of a server. Now all we need a system to map this easy to remember domain name to the associated IP address. And this is exactly where a Domain Name Server comes in. It takes the domain name and resolves it to the associated IP address, which your computer can then use to communicate with the server. So when you type that name into the URL bar of your browser, your computer will perform a DNS query to obtain the IP address which it needs to use to connect to the server.

Take the domain name www.google.co.uk for example, using the tool nslookup we can perform a DNS query to look up the associated IP address, in this case 172.217.18.163:

Screenshot-from-2018-04-05-23-30-01

Privacy

Now as I mentioned before this DNS query takes place over plain text. Below is an illustration of a DNS query taking place, when attempting to navigate to https://www.google.co.uk/. This was take from a tool called Wireshark, which allows myself to sniff all the packets being sent to and from my system, essentially doing what the government, ISP, eavesdropper, etc would potentially do.

Screenshot-from-2018-04-05-23-28-53

As you quite clearly see the host name www.google.co.uk, so I know know you visited www.google.co.uk. Now Google is a benign example, but imagine a more sensitive site. ISPs, governments and other organizations could also use this information to form a picture of users' browsing habits.

How does Cloudflare's DNS help?

Cloudflare's new DNS service tries to combat this by supporting DNS-over-HTTPS as well as DNS-over-TLS With both of these protocols, the DNS query is sent over an encrypted channel. This means that those wishing to obtain which sites you are visiting can no longer do so by viewing your DNS queries.

Below is an example of a DNS-over-HTTPS query performed with the tool kdig:

Screenshot-from-2018-04-05-23-48-29

When viewing the associated traffic in Wireshark we can see that the DNS query now takes place over HTTPS, and as a result I no longer have the ability to see the domain name, in this case www.google.co.uk

We've solved the privacy issue

As seen above with both DNS-over-TLS and DNS-over-HTTPS we can now prevent eavesdroppers from viewing directly what sites we visiting by investigating our DNS queries which are being transmitted over the network. However the whole point of looking up the domain is so that we can obtain the IP address which we will need to use to connect to the server.

Traffic flows across the Internet over a protocol call TCP/IP. With HTTPS, the encryption happens up at a higher level on the TCP/IP model (at the application layer to be precise). Where as the addressing of these packets is happening at a lower layer in the model (at layer network layer). This means the IP address is never included as part of the encryption, nor can it (otherwise how will the packet be forwarded on by systems). Think of it much like a letter, the delivery address (the IP address) is on the outside and easily viewable by anyone who comes into contact with the letter, but the contents of the letter are concealed in the envelop of the letter (the HTTPS request/response).

So what does this IP address mean? Well remember how we can look up the IP address of a domain name? Well the same can be done with an IP address. Meaning that given an IP address, I can then perform what is termed a reverse DNS lookup. Taking our www.google.uk example and assuming that we only received the traffic which the user was browsing:

Screenshot-from-2018-04-06-00-12-59

I don't know what site they are browsing to, but I do know that they are browsing to the server with the IP address of 216.58.206.35. I can then use this IP address to try do a reverse DNS lookup:

Screenshot-from-2018-04-06-00-15-11

Well that's not very helpful, this just appears to be some random host.

Or have we?

Well here are a few things we know:

  1. The IP address used to access the server (216.58.206.35)
  2. This IP address was used to access the server over TLSv1.2

Well TLSv1.2 makes use of certificates, and one of the things certificates have to contain are domain names. These are used to match the domain name which the client is trying to connect to, to the actual server which is being connected to, i.e. certificate hostname validation. Well now all I need to do is query the server for it's certificate and obtain the domain names from the server:

Screenshot-from-2018-04-06-00-26-40

So I can see this certificate is for *.google.com (not off from our original domain name). However due to the sheer number of entries in the Subject Alternative Name (SAN) field, the only thing that I can tell about this IP address is that it is a Goolge server. So my privacy has been kept up to some point.

But this is not always the case. Say I visit the site www.pornhub.com? For those who don't know, PornHub is as the name suggests, a porn site. So this is something which you may wish to keep private! So doing a DNS lookup yields the domain name www.pornhub.com resolves to the IP address 216.18.168.16:

Screenshot-from-2018-04-06-00-31-10

Doing a reverse DNS lookup doesn't reveal anything too interesting:

Screenshot-from-2018-04-06-00-33-17

This is great! No one will know that I'm looking at a porn site! Well one final check, let's have a look at that certificate (after all you most certainly want to ensure that you are browsing your porn sites over HTTPS):

Screenshot-from-2018-04-06-00-35-29

Oh dear!

comic-154301_1280-1

Summary

While DNS-over-TLS and DNS-over-HTTPS do go some way to address privacy concerns, they can only go so far. As you've seen above one can most certainly still paint a rough picture about your browsing habits. Although this picture might not be as clear as before. Take a comparison to location tracking. Instead of being able to track you down to say a radius of 10 meters, you will now only be able to be tracked down to a radius of 1km.
It is by pure coincidence that wildcard certificates provide some degree of privacy, this was never the intention in their design. My worry is that they will now be used solely for the purpose of privacy. This is a really bad idea for security since I feel that wildcard certificates are not great overall in terms of security.

However, security has never about solving things with 100% certainty (although we do try to). It has always been a layered approach, one of which we should make use of all available tools to us. Put it this way, DNS-over-TLS and DNS-over-HTTPS will only help improve your privacy situation, but to some limited extent. The rest is up to you (perhaps don't visit those porn sites might be a start).

Sean Wright
Sean Wright
Experienced application security engineer with an origin as a software developer. Primarily focused on web-based application security with a special interest in TLS and supply chain related subjects.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Sean Wright.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.