According to Google’s own September 2019 transparency report, 94 percent of all HTTP connections are encrypted. DNS queries, however, still travel over the Ether in clear text, as if nothing has changed in the last 30 years. The implications for privacy and data security are undeniable.
DNS over HTTPS
When Amazon’s authoritative DNS servers fell victim to a BGP hijack attack late last April, Google’s recursive DNS service, among others, accepted the fake routing tables and forwarded incoming queries to a fraudulent DNS service that directed them to a spoofed website. The incident illustrates that HTTPS alone is not enough to truly secure Internet communications.
The DNS system (Domain Name System) translates fully qualified domain names (FQDN for Fully Qualified Domain Names) into IP addresses. Fake DNS servers can disguise fraudulent web servers as legitimate web providers, capture login data, and, last but not least, distribute malware. By default, a DNS request travels from the client to the DNS resolver in plain text; any intermediary (any so-called on-path router) can record this communication and thus track the user’s activities.
This scenario actually plays out in reality, sometimes with very unpleasant consequences for those affected. An MiTM (Man in the Middle) can both capture the data for their own “use” and distribute it commercially on the darknet after the fact. Unpleasant side effects include an increased risk of DNS spoofing and profiling by unauthorized third parties.
When a remote hostname is called, the local terminal sends a query to a recursive DNS server (the required address is listed in the operating system settings). The recursive DNS server queries the root servers of the Internet and is referred by the latter to the name server responsible for the TLD (top-level domain) in question. This server then returns the name servers of the relevant DNS zone, which can resolve the hostname into an IP. This entire communication exchange takes place in plain text.
Since the authenticity of the NS information services is normally not independently verified, MiTM attackers can not “just” read the requests, but redirect the communication to manipulated “substitute servers”. There are then hardly any limits to possible misuse. DNS server impersonation poses a serious threat to the integrity of Internet communications.
The Internet community has conceived of several possible solutions, only none of them has yet been able to gain widespread acceptance.
The pros and cons of DNS encryption
DNS over HTTPS (DoH for short) and DNS over TLS (DoT for short) represent two attempts to protect DNS queries from the curiosity of unauthorized parties. Both solutions are IETF standards or RFC drafts. (The IETF, the Internet Engineering Task Force, is a non-profit organization responsible for adopting open Internet standards and is highly respected).
The IETF defines DNS over HTTPS in RFC 8484 (HTTPS and HTTP/2 over port 443) and DNS over TLS (port number 853) in RFC 7858 and RFC 8310. Both protocols encrypt DNS requests but cannot authenticate responses.
DNS over TLS requires port number 853 to be unlocked, making it easy to identify and stop communications.
DNS over HTTPS instead “disappears” quite unsuspiciously in the flood of usual HTTPS communication over port number 443 (instead of traveling through port 53 in plain text as usual). However, DoH also makes it more difficult to inspect data packets in companies. In companies that allow BYOD, DoH is said to make monitoring these devices almost impossible, the harshest critics lament.
DoH meets with approval especially in Europe in connection with the DSGVO. However, there is no lack of criticism either.
DNS-over-HTTPS works at the application level. Apps can internally maintain hard-coded lists of DoH-compatible DNS resolvers, via which DoH queries can be sent. In this mode of operation, it is possible to bypass the ISP’s default DNS settings present at the operating system level. Applications with support for the DoH protocol could thus effectively evade the traffic filters of local ISPs and access otherwise blocked content.
But they do not provide complete anonymity protection. This is because when using DoH, it is still possible for ISPs to intercept other unencrypted parts of the communication. These include SNI fields and OCSP connections.
SNI, short for Server Name Indication, is an extension of the TLS protocol for providing multiple certificates per IP address. OCSP, short for Online Certificate Status Protocol, is a method for determining the validity of X.509 certificates. Incidentally, Google disabled OCSP checks in Chrome by default back in 2012, citing intolerable latencies and insufficient data protection, and relies on its own service instead. This is because the requests from multiple end devices can be aggregated and the anonymity of the individual users can be preserved vis-à-vis the certificate authority.
Firefox uses OCSP stacking instead (i.e. the browser trusts the statements of the website in question instead of waiting for confirmation from the certificate authority, which of course backfires in the case of DNS spoofing) and uses OCSP as a fallback.
However, if the OCSP fallback fails to receive an authoritative response from the relevant certificate authority, Firefox unfortunately silently goes about its business as usual instead of aborting the connection setup. The about:config option security.OCSP.require can be used to disable this behavior.
Be that as it may. DoH is not a panacea. There’s also the whole issue of reliably authenticating the far end of DNS requests.
Challenges of DNS authentication
Another approach called DNSSEC aims to authenticate communications with NS information services of the Internet by exchanging cryptographic signatures. DNSSEC is a DNS extension (short for DNS security extensions) that must be implemented at the registrar. Domain registrars have largely ignored the solution – mainly for cost reasons but also for latency reasons; only about one in ten providers offers it by default.
Because DNSSEC has found only limited acceptance among registrars, it is also incompatible with many end devices and software solutions. In addition, while it can ensure authenticity, it cannot prevent interception.
DNSCrypt, an open-source protocol for authenticating communications between a DNS client and a DNS resolver, is intended to remedy this. But for all the supposed advantages of this solution, no independent standards organization has yet endorsed it. In view of the lack of transparency regarding the true rulers behind DNSCrypt, the utmost caution is advised here for the time being.
DoH with TRR
Google Chrome and Mozilla Firefox can already be used with DoH.
Mozilla has come up with a holistic solution for the DNS problem. In the current version of Firefox, Mozilla combines DoH with a Trusted Recursive Resolver (TRR) from Cloudflare to protect against the deanonymization of user requests. (Optionally, other TRRs can be set in Firefox).
Cloudflare has committed to this by deleting all identifiable data after 24 hours. To prevent third-party on-path routers from easily evaluating communications, Cloudflare relies on measures such as QNAME minimization and geolocation-friendly anonymization of requests.
After all, normally a resolver sends the entire domain name to both the root DNS server and the TLD name server. Cloudflare limits these requests to the really relevant part of the domain name (QNAME minimization) without revealing further details.
A resolver normally transmits a portion of the end user’s IP address within each request; Cloudflare will transmit the IP of its own resolver instead. This allows the service to provide geolocation without having to sacrifice anonymization.
The first request for a URI carries the greatest risk of de-anonymization, as some packets still travel unencrypted through the Internet; however, all further URIs from the server in question can then be transmitted fully encrypted in the already open HTTP/2 channel. This allows the CDN to shield the communication from the eyes of unauthorized parties.
Chrome users can enable DoH in the experimental settings (chrome://flags #dns-over-https).
Conclusion
As long as the DNS system works without any encryption, logging user activity by third parties is easy and DNS spoofing is a danger that should not be underestimated. But even when DoH and HTTPS are used, misuse cannot be completely ruled out. Only a holistic solution like the one from Mozilla and Cloudflare can put a stop to MiTM sniffing.
The DNS system is ripe for a data protection upgrade.
