Today, Firefox began the rollout of encrypted DNS over HTTPS (DoH) by default for US-based users. The rollout will continue over the next few weeks to confirm no major issues are discovered as this new protocol is enabled for Firefox’s US-based users.
[…]At the creation of the internet, these kinds of threats to people’s privacy and security were known, but not being exploited yet. Today, we know that unencrypted DNS is not only vulnerable to spying but is being exploited, and so we are helping the internet to make the shift to more secure alternatives. We do this by performing DNS lookups in an encrypted HTTPS connection. This helps hide your browsing history from attackers on the network, helps prevent data collection by third parties on the network that ties your computer to websites you visit.
We can only hope other browsers will follow soon. This is a very important and great improvement.
The version of firefox I use in linux has not been updated to use this yet, however I do have some technical concerns about this.
en.wikipedia.org/wiki/DNS_over_HTTPS#Criticism
In particular, this technically centralizes DNS lookups to a few select providers (I haven’t confirmed this independently but apparently firefox uses cloudflare and chrome uses google), making it far easier to implement centralized tracking. I know it’s not typical, but since I run my own DNS server this kind of makes my queries less secure (at least by default). And while it’s easy for browser makers to vilify local ISPs, I would argue that the centralized DNS providers technically pose a far greater risk for abuses at a massive scale and possibly make all of us even more vulnerable to secret FISA court ordered wiretapping. Decentralization is normally a good thing and makes it far more difficult to conduct surveillance activities in secret.
The other issue is that encrypting DNS doesn’t technically do much to protect users from passive wiretapping. Local ISPs are still going to get the hostnames and IP addresses and for HTTPS requests anyways since those have to be known (aka unencrypted) in order to route the traffic appropriately to the web daemon holding the decryption keys. Sure the ISP loose the ability to see DNS requests, but they still have the same information through HTTPS deep packet inspection. Now not only does your ISP get the same information as before, but so does another additional party. In effect this adds to and does not subtract from to the number of 3rd parties privy to your activities.
TLDR; Mozilla has omitted some of the facts about protecting user’s privacy, and the articles is guilty of at least unintentionally propagating a false sense of security with this change.
That is an issue, but not an unsolvable one.
Also, the same page says “Firefox 73 added another resolver in the options, NextDNS”, which is a good start.
Maybe a panel which lets you pick from 5 or 6 presets and an “Other” where you can copy-paste one of your choice.
ssokolow,
Yes, I agree, but I feel that mozilla could do a better job of disclosing the privacy risks that they are actually creating. As it stands they’re omitting important facts and leaving people misinformed.
I can’t believe that Google got right and Mozilla got it wrong:
https://www.zdnet.com/article/dns-over-https-will-eventually-roll-out-in-all-major-browsers-despite-isp-opposition/
richarson,
+1
That’s a very good overview of where the different browsers are at!
Unfortunately, they got it right for the US market. The US ISPs are well known for their awful practices, such as customer tracking and selling this tracking data, adding ads to unsecure HTTP content, and abusive pricing policies, lame service and terrible customer service. The US are far behind the EU on bandwidth and internet service quality, and far above in price.
So, hiding DNS data from these ISPs does make sense on a privacy matter and an ethic matter. Even cloudflare is not worse in matters of privacy.
loic,
I’m not sure why this wasn’t clear so I’ll say it again: The ISPs CAN STILL GET THE SAME DATA WITH DPI. So now instead of just the ISPs having the data, it’s BOTH the ISPs and cloudflare.
Additionally this sort of centralization runs counter to scalable & robust network engineering and creates an additional point of failure. Not for nothing but cloudflare DNS specifically was responsible countless intermittent outages and slow loading of the osnews website. Osnews nameservers are hosted by cloudflare, and cloudflare went down several times for months on end…
http://www.osnews.com/story/131339/windows-10-warning-anger-at-microsoft-rises-with-serious-new-failure/#comments
Hopefully the problem over at cloudflare is fixed now, I don’t know if osnews ever reported the problem (cloudflare is still serving osnews DNS with a bad TTL). But it’s quite relevant in highlighting the pitfalls of any plan to centralize key internet services.
Alfman,
The traffic goes through a TLS tunnel so nobody can read the contents.
How then would they still get the same data?
Gargyle, I think he means DPI analysis would find things like SNI When contacting a server you have to send the host name plain text as part of the handshaking in order to get the TLS certificate for the host at the shared ip address. I guess that is Deep packet? Or conversely, the ISP still gets the ip address for all the requests you make outgoing. Some information about who you are trying to communicate can be gleaned from that, but as Mozilla points out with more and more sharing of ipv4 addresses, it will be less useful. In other words, the isp might figure out its a request to AWS, but which service that uses AWS? or Google? or Microsoft? or Digital Ocean, etc. The consolidation of various services to the cloud providers will make providing anonymity a little more likely.
Gargyle,
That’s a great question! I alluded to it elsewhere, but the answer has to do with how the HTTPS protocol tells the server which site it is requesting. There’s a field for “server name identification” or SNI for short. This wireshark screenshot shows what TLS data looks like on the wire…hopefully this illustrates clearly the reason why DNS over HTTPS is not effective for hiding host names against ISP deep packet inspection.
https://imgur.com/10c8cPP
The next obvious question becomes “why?”. Well, consider that a single server can host thousands of clients. Each site will naturally have their own SSL certificates. A server needs to know which website/certificate the client is requesting in order to select the correct SSL certificate to use for a TLS session. only then can the data get correctly encrypted & signed under the certificate for the requested domain. Prior to the existence of SNI, there was no mechanism by which the server would know which SSL certificate to use, consequently an HTTPS server could only have one SSL certificate per IP and it would always answer with a single static SSL certificate. Therefore back in the day every HTTPS website needed it’s own IP. This policy became utterly infeasible for future growth due to the depletion of IPv4 addresses and some mechanism was needed for the client to tell the server which certificate should be used. There are other use cases for SNI as well, such as load balancing, but hopefully this provides sufficient background.
Bill Shooter of Bul,
Yes, you are right.
Obviously when you navigate to a website in the browser, a DNS request is made to get the IP address for a specific hostname, and then the browser proceeds to connect to the IP address. Although DNS over HTTPS to a cloudflare server will hide the DNS request&response from the ISP, the fact is that this same information is going to be sent in plaintext on the wire for the subsequent HTTP/HTTPS request. So now in addition to the ISP having the information, so does cloudflare, having more people in the loop about browser activity is technically worse for privacy. Obviously mozilla knows these facts too, that it didn’t touch upon them is rather disappointing IMHO.
Going by richarson’s zdnet link, google’s approach to DNS over HTTPS could be better that mozilla’s.
I can see why in the US they might choose to do this.
Using HTTPS for most sites already prevented them, the US ISPs, from changing DNS-records or changing the content of webpages (yes they did that, some used to replace adverts !).
But DNS over HTTPS (or any encryption method really). Is part of a 2 step process:
Let’s all remember you need encrypted DNS to be able to solve unencrypted SNI with an encrypted SNI. Because encrypted SNI will probably depends on an extra DNS-lookup:
https://blog.cloudflare.com/encrypted-sni/
I was going to point out exactly this issue, DoH might be fine but Mozilla’s implementation is esentially flawed at the moment.
You run you own DNS resolver? That’s great, run your own DoH endpoint, too. Just configure it in Firefox – it’s “network.trr.resolvers”/”network.trr.uri” setting in about:config.
zdzichu,
Yes, that ought to be possible. I don’t know if/when my DNS software will add this functionality. Maybe I’ll have to run another daemon. But either way this highlights the problem with mozilla’s implementation (as opposed to the implementation in chome and others): it has to be manually configured to use the local DNS over HTTPS resolver. Then when I’m traveling elsewhere and the local resolver is no longer accessible (ie because it’s not running on a public IP), I’ll have to reconfigure firefox again. The amount of babysitting needed to always use a local resolver on a portable device under mozilla’s implementation makes it non-feasible. Hopefully they fix this, but mozilla often do what they want without much regard for the problems they cause. For example, sometimes you find a browser plugin to fix a problem only for mozilla to go in and break/disable the plugin. Unfortunately mozilla is not the champion for open & progressive internet technology that it started out as, at some point they became controlling manipulative bastards 🙁
Serious question: does anyone know if this arrangement between cloudflare and mozilla involves any kind of financial transactions? This could be baseless, but obviously the potential data mining value to cloudflare here is enormous.
Found this while looking at DoH, not sure how up to date it is. But its an interesting idea, to do this via cloud server, thus making it portable.
https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/
Bill Shooter of Bul,
Indeed that is interesting, alas I don’t have enough time to really look into it right now, but maybe in the future. If anyone else gives it a spin, share your experience with us 🙂
But the beauty of this is that you can *choose* your own DNS provider AND you eliminate the privacy problems inherent in the old DNS resolver system. With the centralization, Firefox is able to negotiate a privacy respecting contract with DNS bidders whereas your ISP has no incentive to provide more privacy because usually your ISP is a monopoly with no competition around your area and with all the sleazy things the ISPs have done over the years such as throttling bandwidth on unlimited plans and throttling the websites of competing services like Netflix you can be sure they do anything to make an extra buck.
With traditional DNS resolvers, the domains that you are looking up is shared with your ISP and ALL the DNS servers in between and your IP address is shared too. With DoH (DNS over HTTPs), the “in between” DNS resolvers don’t get to know the full domain name of the website and don’t know your real IP address. That’s the privacy that you are getting.
Arman Tamzarian,
You and I and mozilla know that the masses aren’t going to be knowledgeable enough to change mozilla’s defaults. As engineers it’s rather naive to ignore the problems that centralization poses to privacy, Centralized DNS through cloudflare or anyone else becomes an extremely valuable target for government snoops, they aren’t legally bound by any civil agreement between mozilla or cloudflare, Cloudflare already admits it is logging user data even though there’s no technical need to do it. This thing is barely getting off the ground and Cloudflare’s privacy policy is already disappointing and setting users up for future privacy failures. I also provide DNS but I’ve never needed to log my user’s DNS requests in order to monitor or diagnose their infrastructure as part of my job.
Let me emphasize that I think DNS encryption is good, it’s DNS centralization that is bad. I can already predict articles in the next decade by the next edward snowden revealing that user data is in fact being snooped through centralized DNS providers. The engineers of the internet made mistakes, but decentralization is something they got right. IMHO it’s a shame that mozilla is throwing that away.
I haven’t looked into this yet, but I do wonder what impact if any this will have for IoT and IIoT devices that host web servers.
“We can only hope other browsers will follow soon. This is a very important and great improvement.”
Or not. https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/
While I use Firefox ESR, I did enable DoH. Somehow it feels like a much faster browsing (maybe it’s just a feel?) Also, I’d rather trust Clouflare than my local ISP (I live in the Dominican Republic, they are not too concerned about privacy & fairness).
Caraibes,
I’m going to repeat this again because I think everyone on osnews needs to understand it: enabling DNS over HTTPS now means that you need to trust cloudflare in addition to your local ISP. Your local ISP can get the same data through “deep packet inspection”. The same information that they could get via DNS is still there in plaintext via HTTPS channels due to “SNI”, a feature designed to enable the hosting of multiple HTTPS websites on shared IP addresses.
SNI enables the server to determine which HTTPS certificate to use to encrypt the session. Some may remember that prior to SNI each HTTPS server required a dedicated IP since there was no way to determine which hostname the client was trying to access (and therefor no way of knowing which certificate to use).
And before anyone puts too much blame on SNI, before it every hostname and IP had a one to one relationship, so even if the hostname wasn’t leaked you still had virtually 100% confidence in what site was being accessed through that IP alone.
Erez posted a very informative link above with lots of info, I’m not done reading it yet but it formally lists most of the concerns I’ve been posting above. Also, it brings up other issues I didn’t think of right away like breaking DNS based load balancing and bypassing operating system level adblocking. Has anyone tested whether firefox’s implementation respects the hosts file used by a lot of ad blockers to block ad servers?
You need to read up DNS over HTTPS is only really first step.
https://miketabor.com/enable-dns-over-https-and-encrypted-sni-in-firefox/
“enabling DNS over HTTPS now means that you need to trust cloudflare in addition to your local ISP. Your local ISP can get the same data through “deep packet inspection”. The same information that they could get via DNS is still there in plaintext via HTTPS channels due to “SNI”, a feature designed to enable the hosting of multiple HTTPS websites on shared IP addresses.”
At this stage mostly yes. Thing is when encrypted sni comes default Deep packet inspection will come harder. Yes encrypted SNI is already built into firefox just not turned on by default yet.
Deep packet inspection is a lot more CPU intensive than just recording DNS log and ip addresses. Encrypted SNI without encrypted DNS really does not help because you can use data correlation to guess the Encrypted SNI from the DNS requests. Same with DoH without encrypted SNI that you can work out the DNS bits with the SNI information. Once you have encrypted SNI and DoH job of deep packet inspection will get a lot harder.
oiaohm,
It’s good of you to mention it, but I’m already aware of that standard and Erez’s link mentions it as well. For mozilla to deploy DNS over HTTPS before encrypted SNI is turned on and widely deployed seems just irresponsible IMHO since it reduces user privacy for the majority of users.
It depends, some providers have already invested in equipment capable of deep packet inspection for “network management” (aka throttling). Some are even able to modify traffic on the fly. For example, before osnews became HTTPS only, I would browse to osnews.com and on occasion I would see messages from the ISP at the top of the page. This is something I detest, but the point being this represents a rather sophisticated capability to re-sequence the TCP packets on the fly, the much simpler task of scrapping a domain name is easily within reach for an ISP.
I guess we’re all sort of dancing around the issue of what assurances can mozilla give us that cloudflare won’t abuse its new access to user data? Is there a legal contract? And if so, then is it public?
I couldn’t find a contract between mozilla and cloudflare, I suspect the agreement terms are private. However this is what cloudflare has to say about its commitment to firefox user privacy.
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/
Wow, so they log just about everything for 24H. The problem with logging any data this way in the US is that it immediately becomes subject to government requests. Given what we know about the government’s indiscriminate data collection practices, I think there’s a high likelihood that they will feel entitled to go after user data logged by cloudflare.
At least they say won’t resell the data “without Mozilla’s explicit written permission”, but why add this qualification? Isn’t that suspicious in and of itself? Mozilla has a financial incentive to sell the data just as cloudflare does, I’d much rather see this policy say that cloudflare won’t sell or distribute the data PERIOD. Not even if requested by mozilla. I also feel they log too much.
Of course encrypted DNS isn’t the problem at all, the main problem as I see it is that mozilla’s plan transforms DNS into a centralized service, which has long term dangerous technical and privacy implications.
Really you lot of that information will be collected by Cloudflare be it you use there dns or not due to how much ISP caching they do.
“For mozilla to deploy DNS over HTTPS before encrypted SNI is turned on and widely deployed seems just irresponsible IMHO since it reduces user privacy for the majority of users.”
This is chicken and egg problem. Encrypted SNI without DNS over HTTPS does not provide security either. So for servers to start being modified to provide encrypted SNI in volume you need browsers using DNS over HTTPS and DNS services providing DNS over HTTPS as option kind of first.
I am like you that I wish encrypted SNI could have been done at the same time but it really was not possible.
oiaohm,
This may be the way you feel about it, but to me this logic is absurd. It’d be like saying “don’t worry that this new feature-X being built into the browser sends your data to google (or facebook or microsoft or amazon etc), they collect a lot of that information anyways”. This is not a good justification for giving them more access to our data. Cloudflare is just another corporation to me. So let’s agree to disagree.
It’s not a chicken and egg problem, we SHOULD be deploying encrypted SNI first as a precursor to DNS over HTTPS. It has value *today* in hampering passive wiretapping on corporate networks & internet backbones.
Alfman: “It’s not a chicken and egg problem, we SHOULD be deploying encrypted SNI first as a precursor to DNS over HTTPS. It has value *today* in hampering passive wiretapping on corporate networks & internet backbones.”
You are usually pretty good with this, but we are leaking this information in 2 forms, encrypted SNI depends on encrypted DNS to be useful.
And DNS data is easiest to gather of the 2.
Lennie,
Yes, I know there are multiple data leaks. But DNS over HTTPS provides ZERO benefit until encrypted SNI is widely deployed. You can use off the shelf tools with a few scripts to obtain all the hostname information that was being leaked via DNS. DNS over HTTP fails to provide any protection before encrypted SNI is widely deployed.
On the other hand encrypted SNI does in fact provide some protection against forms of internet backbone wiretapping *today*. Consider when the NSA taps into the internet backbone (such as when they tapped into google’s fiber links, etc). Encrypted SNI would have been able to provide protection from HTTPS hostname metadata snooping that reveal which specific cites users are browsing. DNS requests aren’t as vulnerable for identifying individuals on the public internet due to it’s decentralized nature, caching, and aggregation. Or if you are a corporation running your own DNS servers, your own DNS servers are clearly less of a privacy concern to you than hostnames being leaked out of HTTPS connections on the internet via SNI.
There’s no benefit in deploying DNS over HTTPS before encrypted SNI. But conversely there IS at least some benefit in deploying encrypted SNI first to protect against known internet wiretapping threats even before DNS over HTTPS. My hope is that we can agree on these facts.
You ISP can inspect your traffic, but they can’t change it and can’t perform MITM attacks using the DNS. If you remember a few years ago ISPs would hijack unresolvable domain names and show their own websites filled with ads by fiddling around with the DNS resolver.
There’s one thing you’re forgetting.
With traditional DNS resolvers you are trusting your ISP and all the DNS resolvers in between.
For example if you DNS look up “phartshield.msk.ru”, firstly your ISP knows, then the DNS resolver at “.ru” knows, then the DNS resolver at “.msk.ru” knows, then the DNS resolver at “phartshield.msk.ru” knows and each of those DNS resolvers knows the full domain that you are trying to access (“phartshield.msk.ru”) and they know your true IP address.
With DoH and Cloudflare, firstly Cloudflare will mask your IP address with an IP address belonging to Cloudflare that is physically near to you (so that you get matched to servers nearby). Any intermediate DNS resolvers won’t know your real IP.
Secondly Cloudflare will ask “.ru” for the DNS resolver for “.msk.ru” (instead of providing the whole domain name “phartshield.msk.ru”) so that “.ru” only knows that you want to go to “.msk.ru” and then finally it will ask “.msk.ru” for “phartshield.msk.ru”. This technique allows intermediate DNS resolvers to not know your final destination.
All in all, with DoH you only need to trust your ISP, trust Cloudflare and the final destination. With traditional DHS resolvers you have to trust everybody in between.
Arman Tamzarian,
While using cloudflare with DNS over HTTPS takes your ISP out of the loop, it does nothing to address the trust problem between DNS resolvers. Cloudflare’s DNS resolver is technically just as fallible. There are ways to robustly fix this with a cryptographic chain of trust, such as what DNSSEC provides, but it’s not really clear that the internet is ever going to widely embrace it. 🙁
There’s a very lengthy discussion about the current state of affairs.
https://www.bluecatnetworks.com/blog/dnssec-dns-over-https-dns-flag-day-whats-the-difference/
You don’t need to explain it to me, I know this. I’m just pointing out the fact that until encrypted SNI is deployed, your ISP has the data regardless of whether you use DNS over HTTPS or not.
“We can only hope other browsers will follow soon. This is a very important and great improvement.”
I couldn’t disagree more. Name resolution doesn’t belong in the browser at all – full stop. This should be a function of the operating system. What about other applications? Does name resolution not need to be secured for them as well?
This needs to be adopted at the OS level to cover security of name resolution for ALL applications, not just web browsers.
The problem is: operating systems aren’t adopting anything.
Well, Android is and systemd-resolved is on Linux.
But Windows and Apple don’t seem to have any plans as far as I can see.
Not true, Windows has plans to adopt DoH. In fact, with chrome’s DoH enabled it checks the operating system to see if windows 10 has a DoH compliant DNS server configured before it uses one itself. Enterprise Security software is taking advantage of this to maintain some level of control over the DNS requests.
https://www.bleepingcomputer.com/news/microsoft/microsoft-is-adding-dns-over-https-doh-to-windows-10/
‘
In particular, this technically centralizes DNS lookups to a few select providers
‘
>
>
Of course it is, and they’re most likely kickbacks towards Mozilla for doing so.
You seriously don’t think anyone is going to get involved with something like this without cash being passed around,do you?
.
All right, guys, so basically, you are all saying I should just forget about DoH, and go back to the old way?
Caraibes,
I think other posters will be upset if I say “yes”. However the candid answer is that until there’s widespread deployment of encrypted SNI you’re still transmitting all the same data hostname & IP data in cleartext anyways. Enabling DNS over HTTPs in firefox enables cloudclare to log your activity as well, making it two entities you’d now need to trust instead of one.
If you don’t trust your ISP, you might consider a VPN, which really does hide everything from your ISP. For privacy sake I’d recommend you pick a VPN provider that doesn’t log anything.
I mean with a VPN you’re just moving trust from the ISP to the VPN company. I’m not so certain that’s a great idea in general. I kinda just want anonymous communication between myself and the intended server without having to trust anyone but the server, and one of many trusted third parties that can authenticate the server is who I think it is without that third party understanding who it is I’m asking about.
Bill Shooter of Bul,
Yeah, the suggestion was for those who said they don’t trust their ISP, but I agree with you. Whether you’re sending routing your traffic or dns requests through your ISP, a VPN provider, cloudflare, google, etc, you’re not really eliminating the trust element, you’re just shifting it around between companies.
The Tor network probably gets you close to what you want since it’s very difficult to match the source and destination. Obviously tor has it’s own cons too. I don’t know when encrypted SNI will be widely adopted, but until then the tor exit node is able to see the HTTPS hostname via SNI.
No.
You also get other security benefits from switching to DoH. Namely it protects against DNS Hijacking.
https://www.ietf.org/proceedings/99/slides/slides-99-maprg-fingerprint-based-detection-of-dns-hijacks-using-ripe-atlas-01.pdf
Some countries have > 25% chances of DNS being hijacked and the risk does not necessarily come from a government. There are many hijacks in developed countries (e.g. US, UK, Italy).
Arman Tamzarian,
That’s true, thanks to the fact that DNSSEC isn’t widespread 🙁
However it should be noted that DNS hijacking to take over websites is only effective for HTTP and not HTTPS. Even if your ISP hijacks the IP, it still only sees the encrypted stream and cannot hijack the website.
In my experience this is most prevalent with hotspots in order to redirect users to a login page or conditions page, but this doesn’t work with HTTPS. In terms of privacy either you are using HTTPS, in which case the ISP cannot see or change the contents regardless of IP hijacking, or you are using HTTP, in which case the ISP can both see and change the contents regardless of IP hijacking. So in principal I agree the ISP should not be changing DNS results (what DNSSEC is all about), but in practice HTTPS provides the privacy and authentication regardless of IP.