DNS over HTTPS (DoH) is already here: the controversy is served

Recently, the IETF has raised to RFC the DNS over
HTTPS proposal. In other words, this means resolving domains through the well-known HTTPS, with its corresponding POST, GET and certifications exchange for authentication and encryption. This new is more important than it may seem. For two reasons: firstly, it’s a new resolving paradigm that shakes network foundations. Secondly, because the support of having RFC combined with the interest shown by browsers (greedy for the power granted by this) has led them to start its implementation in record time. It is said that privacy is granted, ok, but… Is it a good (or bad) idea?

DoH (DNS over HTTPS) is really simple. Instead of going to port 53 of a server (for instance, the well-known 8.8.8.8) and asking for a domain through an UDP or TCP packet, DoH standardizes the construction of a GET or POST to a HTTPS domain, so the answer will be the A and AAAA records (the RFC doesn’t specify other records) with the IP. It has more details, such as the clever solution of turning the heading cache-control into the TTL. Everything encrypted carefully, of course. Do you remember when in a hotel you could tunnel the HTTP browsing via the DNS protocol (often unrestricted) to avoid paying the Wi-Fi? So now it’s the other way around.

How have we reached this point?

The DNS protocol is like a camel. Over time, it has been carrying so much weight –patches, remediations and plugins–, that now it is walking through the desert without completely solving any problem except those for which it was designed. For some reason, the desired security and privacy haven’t even been achieved yet; and this is not because they haven’t been proposed (in fact there are dozens of alternative proposals, even complementary to each other), but because none of them has been implemented massively. Ranging from DNSSEC to DNS over TLS (DoT), as can be imagined, this latter means keeping the same DNS protocol, but with a TLS tunnel (something like POP3 and SPOP3). DoT (the closest to DoH) uses the port 853 and, indeed, also hides traffic content and authenticates the server. This RFC was proposed in 2016 but, contrary to expectations, it has not found its way. Anyway, it has not caused the stir raised by DoH.

By the way, there are also DNS over DTLS, DNS over QUIC, DNS over TOR… even a DoH that returns a Json, but this is a special adaptation used by Google (also by Cloudfare) more powerful (since, for example, it allows to check other records different from A
or AAAA).

Usa DoH a través de las APIs de Google y Cloudfare imagen

In these images you can see how use DoH through the
Google and Cloudfare’s APIs and how it returns a Json

Why such a stir?

DNS is one of the oldest protocols of the network, and it has been always a bottleneck for security (ranging from the birthday attack to the Kaminsky’s flaw): clear text, potential UDP (so facilitating even more false packet injections). This represents a disaster even without attacks, since servers can be under governments control and then queries can be redirected or blocked. And all this in full transparency and without privacy nor integrity (since DNSSEC is not as implemented as it should be). We have entrusted Internet foundations to a protocol that could not technologically protect itself against massive implementation of solutions (or such a protection has not been wanted, for the same reason). A protocol to which all kind of patches and wraps have been applied to avoid breaking tradition, to the extent that finally the proposal to get security has been ground-breaking: placing resolving to data framework. If this were not enough, DoH makes that resolving does not trust the system’s global DNS, so it could ignore the DNS server usually provided by DHCP. In this way, each application could resolve via HTTPS by default.

But this does not seem harmful, right? Would not be wonderful that no one could see what we are trying to resolve and consequently could not modify it by any means? Hiding under the HTTPS queries and replies and going with the flow within a port that nobody can block: the port 443. No more spies and constraints. This is what DoH offers but, is it actually advantageous?

Browsers are happy implementing it. It’s their opportunity to be powerful, not just because they already know this technology HTTPS, but also because it allows them to implement the resolver to be queried by default within the browser… For instance, Google could not access to whatever is resolved through its famous 8.8.8.8, but it would extend its percentage of DNS’ users (around 13 %) to everyone using Google Chrome, 60 % now. It has been named “secure DNS”. They have seen the opportunity to break out of the system DNS exactly through the point where most domains are resolved: the browser. Google is already using DoH on Intra (released by Jigsaw Operations), which precisely is used to elude DNS blocks.

As for Android, it implements DNS over TLS on its last release, although it has not spread it so much. Currently, Cloudfare has also entered in the DNS business, so the 1.1.1.1 company is working with Firefox to provide reliable resolve. In fact, in Firefox DoH is known as TRR (Trusted Recursive Resolver). It promises not to use the bunch of users’ data that it may need. For example, Cloudfare is engaged to remove that sending of the 3 first octets used in a DNS query. This sending is a movement (with RFC) promoted by Google and OpenDNS in 2011 to improve DNS performance through IP location.

Chrome has implemented it, but they don’t have an appropriate interface yet. They’re working on it. https://chromium-review.googlesource.com/c/chromium/src/+/1194946

Firefox has already integrated it, disabled by default

Nobody has considered the problems derived from SIN or from false certificates?

To be honest, there are two serious problems, both derived from TLS itself. The first one, that the cleverest ones may have discovered, is that, currently in the TLS world, the domain visited is clear. If someone monitored a TLS communication they would only see the domain itself, but not the customer-domain communication. This is because of the SIN (Server Name Indication), a parameter which is naturally exchanged over the TLS communication process. The pro-DoH agree with this, but they say that it will change soon. In 2017, this RFC establishing how all the TLS communication will be encrypted (including the domains visited) was accepted as a draft. If this is encrypted on the TLS, the DNS over HTTPS resolving query itself will be completely invisible and, finally, private. How long must we wait for this? No one knows it. People have faith that TLS will implement it.

However, beware! Because a potential traditional resolver (behind DoH) could see the domains queried, so at a moment it would be possible to “go back” and check who queried what.

Maybe the logical option would be using DoH as interface and DoT in the servers that are able to search the domain within the query background. And all this adding DNSSEC, since it’s fully compatible (it adds integrity) and they have different functions.

Moreover, another serious problem from TLS is the use of false certificates within the server, since they enable encryption breaking and spying. This bad practice is accessible for governments and, paradoxically, also constitutes a weak point of DoH derived from using TLS, especially when DoH has been designed specifically to ensure that governments can’t limit Internet through the traditional DNS. Any government could intervene only by using a false certificate also in the DoH (as sometimes done for other web pages).
Although DoT requires pinning use on its RFC, in DoH it’s not even recommended… Didn’t they plan to do it?

https://business.blogthinkbig.com/wp-content/uploads/sites/2/2019/04/doh5.png?resize=640%2C252

As observed, in DNS over TLS pins are indicated (dnsprivacy.org), contrary to DoH.
They even advise against it.

To get the pinning, like other solutions (for instance the extinguished HPKP), after the DoT TLS handshake, the customer shall estimates the SPKI from the certificate based on the public key as well as other data from X.509. Exactly as the HPKP pins, but without first transfer. The customer must know and store them in advance.

The browsers’ role and where this leads us

Because of this, the well-known Internet paradigm may be broken. At least, it raises doubts. In fact, Paul Vixie (one of the DNS’ developers) is radically against it, and promotes the use of DNS over TLS instead of DNS over HTTPS. Some of his reasons are (even if it sounds grinchy) that analysts will lose control over the network, the monitoring ability, signalling and data protocols are confused… It is necessary to take into consideration that this model gives even more power to the browser and, consequently, to that one having the greatest browsing share now: Google. In this regard, Firefox has a more transparent policy, although Cloudfare could get interesting information thanks to its partnership. Anyway, are we centralizing so much DNS, a system decentralized by nature?

DoH is simply a new way to use DNS, and behind it the server queried can do whatever it wants (something that it already does) and it will actually do the same as any network resolver. The protocol itself does not change, what is modified is: How to access it and Who can get such access. The encryption regarding DoT does not change either, but now such encryption is done through a port 443, that hides the remainder of the encrypted traffic and then the DNS resolving is lost within the rest of queries. Just as the malware learnt (to neutralize firewalls’ reputation) to locate the server outside the network (instead of turning the victim into a server by opening a port); just as it understood later it was better to stop using strange ports (for instance, IRC) and communicating via the port 80, or later even via the 334. Just in the same way as we have transferred our hard disk to the cloud, and every application to the browser: DNS joins this trend, so its traditional functioning is reconsidered. All this raises doubts on how resolving will be set within the systems. Imagine that what was feared from governments could be done now by the applications developers or the major DNS owners, or on the contrary: in the future, maybe we will be able to download applications with their own DoH, and we will accept changes in the DNS queries only by accepting the terms and conditions –that nobody reads…

What about the power of filtering domains at the DNS level? It would not be possible with DoH, since the browser could keep visiting that phishing or command a control even if you have previously blocked it on the company DNS. Are we doing malwares a favour in exchange for user privacy and browser power?

However, DoH also opens new possibilities. For this to work, the multiplexed HTTP/2 is used, opening in turn other ways, due to the push that allows to resolve more domains in one go. Moreover, it allows to reduce the SNI leakage. Why? On HTTP/2, connections are reused. From the first connection to a site, the browser can know other sites hosted by this server and consequently reuse this connection for visiting. When connections are encrypted… Benefit is retaken from the channel without sending again the SNI. Since not lots of web pages are located in one server, this will happen most of the times.

In short: locally, pay attention to your browser and if you confirm something strange when resolving domains in your systems, you already know what may be happening; globally… we will see the new paradigms derived from this protocol.

Sergio de los Santos
Innovation and Labs (ElevenPaths)

A story about two minds: the vast difference between real and perceived riskYou are less rational than you think when you take decisions under uncertain conditions