Mozilla Tests DNS over HTTPS: Meets Some Privacy Pushback

Mozilla is testing a method of securing DNS traffic via HTTPS, but is faced with some privacy resistance.

The Mozilla Foundation is testing a new mechanism for securing domain name server traffic that uses the encrypted HTTPS channel. It is an attempt to speed up the internet, reduce the threat of man-in-the-middle attacks and keep prying eyes from monitoring what users do online.

Starting in the next several weeks, Mozilla plans to run tests using a developer version of its Firefox browser with the help of the Mozilla developer community and content management and delivery network firm Cloudflare. Developers will be testing a proposed standard called Trusted Recursive Resolver via DNS over HTTPS, or DoH for short. The standard is winding its way through a draft process and is scheduled to be voted on for ratification by the Internet Engineering Task Force (IETF) later this year.

However, despite potential gains in speed, security and privacy, some have expressed concerns pointing out that centralizing DNS traffic through gatekeepers trades one privacy problem with another.

Some of those reservations over DoH have surfaced over the past week in the run-up to the full-fledge test of the service among Mozilla developers. Developers don’t like the fact that the testing of the service will be opt-out and uses the third-party service Cloudflare.

“At Mozilla we work in the open. We are soliciting feedback on a study that is not yet underway about DNS over HTTPS. We are currently exploring what the right testing approach should be with users who have opted to participate by using Firefox Nightly,” said Selena Deckelmann, senior director of engineering at Firefox in a statement to Threatpost.

“We feel this technology could provide important protections against spying on people’s web browsing. The way the web currently works, DNS traffic is unencrypted and shared with multiple parties, making data vulnerable to capture. Our proposed study would explore if there is an alternate and potentially more secure way to manage DNS traffic by first encrypting it,” she said.

DNS Security, Privacy and Efficiency Primer

Currently, a user’s internet service provider is most often the only party privy to DNS requests made by a browser, primarily because the ISP alone is responsible for the routing of that request. Nearly everything a user does online begins with a DNS query. Its function is to map domain names (such as example.com) to the actual IP address of the server hosting a desired webpage.

DNS queries are sent in clear text (using UDP or TCP) and can reveal the websites a user visits along with metadata such as a site’s name, when it was visited and how often. In other cases, when content filters are in place, DNS logs can capture user IDs or MAC addresses. And thanks to a loosening of privacy rules by lawmakers, now ISPs can share their users’ internet activity with third parties.

Privacy activists also note that DNS spy tools such as Morecowbell and QuantumDNS (PDF) have been used by governments for covert snooping.

For these reasons DNS is considered one of the leakiest aspects of the internet’s plumbing.

“DNS is a 45-year-old protocol. It was never built to have encryption in it or be secure. Yet, DNS acts as the internet’s vital directory and is vulnerable to many different types of abuses,” said Matthew Prince, co-founder and CEO of Cloudflare in an interview with Threatpost. “This is a privacy nightmare. This is a security nightmare. And, this is a performance nightmare, and yet it’s the foundation on the internet.”

He argued, man-in-the-middle (MiTM) attacks often exploit the insecure nature of DNS via DNS Spoofing attacks or DNS Hijacking or DNS Poisoning. MiTM attacks involving DNS are when a hacker can abuse DNS servers to redirect webpage requests and return spoofed sites (or files) that appeared to be legitimate.

By putting DNS in an HTTPS encrypted channel the ISP (hotel or café Wi-Fi hotspot) can no longer eavesdrop on DNS queries. It also makes it harder for hackers to hijack or spoof DNS activity in order to leverage a MiTM attack.

Then there is the matter of efficiency and reliability. Cloudflare maintains that using a DNS resolver via an HTTPS request is more efficient and can shave up to 15 milliseconds off the time it takes to make DNS queries to render a webpage. Even more milliseconds can be shaved when Cloudflare acts as the authoritative DNS hosting service, Prince said.

DoH efforts spearheaded by Mozilla, began in late 2016 informally. In July 2017, the IETF met in Prague and began work on standardization of how DNS over HTTPS would work. Stakeholders have met several times since and the IETF Steering Group could approve a standard in around 4-to-8 weeks or ask for changes, according to those familiar with the process.

The current DNS over HTTPS “draft-04” is expected to leave the working group and be submitted to the IESG (the IETF Steering Group that reviews all Internet Engineering Task Force Standards) in April.

Criticism and Facebook Privacy Jitters 

While many cheer the upsides of using the encrypted HTTPS channel to secure DNS traffic, there are some that caution that doing so trades one privacy and security problem with another. They argue, by routing traffic through a content distribution network management system (such as Cloudflare and others) they are creating new central repositories for DNS queries that could be hacked or used to mine personal identifiable information (PII) data.

Supporters of DoH argue that the standard is still in draft mode, and that Cloudflare is only being used in the testing. They say there would be many DoH DNS resolvers run by everyone from commercial companies to non-profits.

In the interim, some users have turned to VPN services in hopes of barring anyone from tracking them online. However, many VPN solutions still leak DNS queries by sending them unencrypted to their ISP. Last November, Google launched its own flavor of DNS over HTTPS that complies with IETF draft standards. Users can configure their browser to use what it calls Google Public DNS.

In Google’s DoH test its privacy policy states:

“Your client IP address is only logged temporarily (erased within a day or two), but information about ISPs and city/metro-level locations are kept longer for the purpose of making our service faster, better, and more secure.”

“Not retaining IP addresses is good. Can they perform aggregate tracking of hostname requests, or tie common hostname requests from an origin together somehow? What is our recourse if they break this agreement (the recent Facebook debacle seems likely to make folks jumpy),” wrote one developer on a Mozilla developer forum.

Cloudflare’s Prince told Threatpost:

“We are committed to not storing any DNS logs for the service for longer than 24 hours. We don’t write the source IP addresses to disc – which is the only data that could identify a customer. We have no interest in being a centralized repository for PII. Our business model is not advertising and it’s not about saving data.”

Granted concerns expressed on the Mozilla developer forum are mostly directed at testing, it could be a harbinger of robust privacy debates to come if or when the IETF approves the standard.

“Obviously, using a central resolver is the downside to this approach – but it’s being explored because we believe that using the right resolver can be a net win compared to the disastrous state of unsecured local DNS and privacy and hijacking problems that go on there. It’s just a swamp out there,” wrote Patrick McManus of Mozilla, one of the Internet-Draft’s co-authors.

“For this test that means the operator will not retain for themselves or sell/license/transfer to a third party any PII (including IP addresses and other user identifiers) and will not combine the data it gets from this project with any other data it might have. A small amount of data necessary for troubleshooting the service can be kept at most 24 hours but that data is limited to name, DNS type, a timestamp, a response code, and the CDN node that served it,” McManus wrote.

Still the cat may already be out of the bag for DoH in some form. Cloudflare said it was already in talks with or testing DNS over HTTPS with most browser makers, operating system companies, large app developers and router manufacturers.

“I believe there is going to be a lot of choice in the market. Consumers will be able to make decisions on their DNS provider. I fully expect many more players in the market and that’s a good thing. It’s only going to make the internet more secure, more efficient and more private,” Prince said.

Suggested articles

Discussion

  • TuxRuffian on

    I'd rather see better support for dnscrypt which this article doesn't even mention...
  • Renato Gentil on

    DNSSEC would avoid any hijacking or spoofing issues with DNS. You can imagine for every query that you have to perform, you would have to go through the 4 way handshake HTTPS process....it would be a nightmare, specially if there is cipher issues, etc..
    • Kevin on

      DNSSEC solves a totally different problem. DNSSEC queries and responses are not private, and can be seen by anybody. DNSSEC only prevents spoofing (by signing, not encrypting, RRs). DNS over HTTPS encrypts the traffic and prevents snooping.
      • Anonymous on

        Yes, but I was referring to DNSCRYPT not DNSSEC. Other than using TCP instead of UDP, which I suppose could be advantageous in some situations, what advantage does DNS over HTTPS have over DNSCRYPT?
  • Mark on

    A browser would usually establish only a single DoH connection to a server on startup, so no concerns about constant TCP connection setups/teardowns need worry you since multiple queries would be sent over the same connection. There's been a *lot* of research over the last few years to make http2 blazingly fast too. Also, all of the regular caching semantics for http still apply too. It will be fast...
  • Petrol on

    This is really about centralizing everything and bypassing local DNS policy including DNS based filtering services intended to PRESERVE the end users privacy. DNS is one of the last services many ISPs still run in house and offer to their customers. To say DNS over HTTPS is faster is hilarious. One cant even send data over a TCP connection in the round trips it takes to get a DNS response let alone doing the same over HTTPS. To say someone could spy on DNS queries because they are transmitted in the clear is true. Yet the reality is encrypting does very little because IP header is unencrypted. Assuming HTTPS both the servers certificate identity and client SNI are in the clear so it's never a secret where you are going anyway. To say that securing DNS improves security is true but not by much given the fact resolved addresses are themselves insecure. The entire network isn't trustworthy including underlying routing protocols. Anyone who can hijack your DNS can probably do the same to your packets. DNS itself needs to be improved not totally subjugated.
  • commandline on

    The encrpt everything hype is a disaster. A F.U.D. weapon of mass manipulation. The use of NULL ciphers with any kind of encryption while relying on strong signed messages and strong transport encapsulation is the key to an elegant mix of encryption and signed traffic. The users can work with certainty their requests are handled in a trusted way. Any security equipment can monitor and build intelligence for reliable threat detection. Pushing forward with "encrypt everything" has pushed us as a society to the brink of peak paranoia. By now there is talk about encryption backdoors, basically permitting control of any computer involved. There is need for encryption, sure, plenty even. But encrypting everything is a system of leverage, not a desirable solution. The TLS 1.3 WorkGroup did not even bring up NULL ciphers. So these are not included and could not easily be included but by incorporation as an update into the RFC.
  • Moonchild on

    Trying to work around untrusted local networks on a service-by-service basis is total nonsense. If you cannot trust the local network, no service should be used in the clear on it, so the solution is very simple in that case: use a VPN through a trusted host. It's also no a browser's task to try and provide NETWORKING security, Mozilla shouldn't try to be a service provider and focus on improving their software instead. We don't need this -- better solutions already exist.

Leave A Comment

 

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.