DNS over HTTPS is a great idea. There's nothing wrong with the protocol or Mozilla's implementation of it. This article is all about Mozilla's default choice for a DNS provider. I think Cloudflare is actually a reasonable choice though I'm not a big fan of their annoying captchas that I get served whenever I use vpns.
There's nothing sneaky going on here; which the article seems to imply.
Currently there is no UI to configure any of this yet (other than about:config) but you can trivially select any DNS provider that implements this in the same place where you turn this on. The relevant setting is network.trr.uri. Also, you need to opt in to this to turn it on so you'd be reviewing this setting as well. Also you can configure how this is used, how and when it falls back to normal DNS, etc.
You can run your own server if you want; or use the one from your provider if/when they implement this. For obvious reasons, there are not a lot of usable servers yet but it seems Google has implemented this as well. So I assume they plan to roll this out for Chrome at some point.
The premise of this article seems to be that you should trust your provider to do DNS and do it well. I'm sorry to say but for the vast majority of providers I have experience with the opposite is the case. I've had providers redirect dns failures to advertising pages in the past, shitty performance (600 ms or worse), and generally trying to rip me off with bad network infrastructure related outages while charging me a premium for bandwidth clearly not delivered via obviously very congested infrastructure. I have no reason whatsoever to trust them, at all. The less they can learn from my traffic the better.
The article doesn't suggest there's something sneaky going on. The article is suggesting that Mozilla are choosing to share your DNS queries with a third party service by default, which is exactly what they're doing. It's not about them choosing Cloudflare in particular, it's about them choosing any particular service by default. And the article's argument that, if you have to choose somebody to share this data with, it might as well be the people you already share it with, seems pretty valid to me.
edit: I have to point out that the article has backed away from the claim that this will be enabled by default in September. Looking at the Mozilla blog, they mention wanting to enable this by default but have no actual plan to do so (and more crucially doesn't discuss at all what sort of form it would have to be in for them to enable it by default, it may look nothing like the cloudflare-default we're discussing here).
That’s simply not true. Mozilla is not sharing DNS queries with Cloudfare by default, nor are they overriding your configured DNS servers per default. This is an experimental opt-in feature, and they are also running an opt-in study. There has been no announcement of an ”on by default” for DOH. If you enable the experimental feature there is no default provided and you have to set your own server, but if you opt in to the study, you’ll get Cloudfare. This is almost pure FUD at this point.
Just to be clear, the authors are wrong? There will not be a September patch that overrides my network DNS settings?
"With the next Mozilla patch in September any DNS change you configure in your network won't have any effect anymore, at least for browsing with Firefox, because Mozilla has partnered up with Cloudflare and will resolve the domain names from the application itself via a DNS server from Cloudflare based in the United States."
This is the relevant post from the Mozilla nightly blog: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr... It confirms that the default is off. It also gives a much more nuanced view of the level of partnership. CF is currently the partner for a study regarding that feature. That study still requires opt-in (and currently nightly) The patch in September will bring the feature to mainline FF, but it’s still default off and hidden behind “about:config”
Do you seriously believe that Mozilla is issuing a patch in September that will somehow force you to use Cloudflare as a DNS provider? That 'any DNS change you configure in your network won't have any effect anymore'? Do you know many setups that would break?
> We believe that negotiating a privacy first operating agreement is something that Firefox can do for people that is just impractical to ask them to do for themselves. Imagine calling up your residential ISP and asking them to agree to an audit that demonstrates they do not log your IP address on their DNS server. And then repeating the process for your favorite coffee shop, library, friend’s house — anywhere you and your browser go to connect.
Firefox improves user privacy by default by finding good partners, establishing legal agreements that put privacy first, and eventually shipping a default configuration we believe is best.
They know about the power of default settings - and with the current default, they will be unable to roll-out this feature to a meaningful number of users. So at some point, the default will probably change to activate DoH.
Technically, this isn't "force" as you'll probably be able to turn it back off via about:config - if you know which options to change, what to change them to and if you are willing to click past the "if you proceed, you may damage your computer" warning.
Not every random guest that wants to access your local Nexcloud instance will be willing to do this.
And you expect that to happen within the next month? Without any warning that it will happen with the 62 release? After they have just started an experiment intended to shake down the feature on both the server and the client side? Even after having it default off in nightly? With no practical experience of how a large-scale DoH setup behaves in a real-world environment? Breaking all setups that use an internal DNS to resolve internal names (such as any larger-scale corporate setup)?
If you intend to say “sometime in the unspecified future Mozilla will probably default to this.”, then I’d agree but this is not what’s being discussed. At that point in the future, the whole environment in which this is operating in will look different. More DoH-capable providers, a better understanding of the benefits and drawbacks, a config UI,...
Hmm, looks as if the September date was indeed an error - even the article added a correction. (Also a Mozilla representative seemed to post they plan to keep local DNS as fallback)
So I do hope you're right and they will take their time until the ecosystem stabilizes and they found less damaging strategies.
I still think there are general problems with DoH and the assumption that all local networks are hostile. But maybe, there will be more time to discuss those assumptions.
I don't see that they will necessarily add a config GUI though. Most people will likely ignore the feature and the techies already have about: config, so there might be little pressure to add a more accessible UI.
I don't see how they could enable it by default unless they query both local and DoH at the same time .. or perhaps a hybrid model where they only using DoH by default on certain TLD's and / or domains.
Corporate users would be utterly broken unless their IT staff are managing the proxy settings in all their installed browsers, which is often not the case. This would lead to Security and IT staff blocking CF DNS until it was fixed.
I believe this is a good thing to watch for, but I can't imagine Mozilla not having thought this through.
The default applies currently if you enable an experimental feature. They hammered out a tight privacy agreement for one service and use that as default while this is stabilized. You can pick any other resolver if you prefer. Seems a legit way of handling this.
> And the article's argument that, if you have to choose somebody to share this data with, it might as well be the people you already share it with, seems pretty valid to me.
The whole point of HTTPS and DNS-over-HTTPS is to not share any data at all with your provider. It’s not entirely working right now due to SNI being plaintext, but work is being done on that, too. So that’s really not a good argument.
Most Firefox users are absolutely unaffected by this. Literally all people that don’t explicitly enable this. All those who do might want to make up their mind if they want to participate in this and if they want CF to be their provider of trust. Keep in mind that CF will see a substantial chunk of the traffic anyways.
Mozilla seems to be confident in that agreement and I have a certain amount of trust in Mozilla which factors into my decision. Yours might be different, so don’t enable that feature or use a different provider.
FF will turn this on for everybody and Cloudflare will be the default 2018? Don't know. 2019? For sure. All FF browsing meta data flows into the US, the country with the most spies and no legal framework to go to court.
So your argument is an obvious straw man and one wonders about your motivations to support getting all the browsing meta data into the US by default.
Moving my data from Germany to the US will not make me more secure in any way.
And talking about repressed countries is like "think about the children!" for the rest of us - a nice lever to sell this massive data vacuuming.
Why do you believe that this will be default on at any time in the near future without a reasonable configuration UI and without a reasonable set of DoH-capable nameservers? Especially given that this would break a substantial number of existing setupts? If you have this little faith into the FF/Mozilla folks, why do you keep using FF? If you’re not using Firefox, what are you concerned about?
The section of people that use it might benefit to a very large degree. Or they can make the switch prominent to push adoption. There are a lot of features implemented and hidden behind “about:config” where you could ask the same question. Many of them are for the security and privacy conscious but come with a few strings attached, for example some advanced cookie settings such as third party isolation.
That said: I fully expect that at some point Mozilla will want to push adoption of this feature, but not in its most extreme form. I’d expect that a default configuration would use soft fallback.
Which I think is the purpose of almost all experimental feature.
In the blog it is clearly stated that they hope DoH implementations will become standard and common, maybe that even some ISP start offering their own.
Why does so many people distrust every single step done by mozzilla!?
Sorry, this got me emotional, but since I started following tech news few years ago the amount of fake news on mozzilla I read is astounding.
And proper fake news. Many, as this article does, do no claim that a new feature dangerous per se, but falsely (I don't think with purpose, that is what I find astounding) quote mozzilla blogs to build an apocalyptic scenario
In today's world, it's important to remain skeptical of companies who are responsible for how our data and usage statistics are used or shared. Companies have generally shown themselves to be untrustworthy and it's not enough for a company to have been 'good' so far. We need to stay vigilant, even if it is Mozilla.
I believe Mozillas goal is to use the collective bargaining power of it's user-base to get favorable terms and conditions from vendors like cloudflare.
This could include 3rd party reviews, etc.. Who knows?
That wouldn't stop legal threats. Per Core Secrets leak, NSA/FBI both pay for and force backdoors in U.S. companies' products. They also share that information with other enforcement organizations per other leaks. Cloudfare are in a position to monitor lots of network activity. I'd be quie surprised if they weren't already backdoored.
If NSA/FBI aren't in one's threat profile, one might also be concerned about a court order over something having to do with copyright or patents. Damages for those can be huge. There's both legal and technical firms dedicated to pouring through data for evidence of patent infringements. Many licensing "agreements" start with evidence they find. I don't know much more about this. My wild guess is that they often start with tips from disgruntled workers or maybe those leaving for competitors.
These are main, three threats I'd be concerned about if sharing what I did with a U.S.-based provider. Double true for me given I'm in the jurisdiction of the enforcement agencies.
Let me be more specific: they might be fined out of existence and/or executives do prison time if they don't comply. They'll also be told to lie to preserve both the collection method and their businesses' success. Read the Lavabit case records to see FBI doing that. So, they'd be forced to comply and lie to you about it in that scenario. In such a scenario, faking transparency reports would support the lie and/or do some good showing they're stopping other threats. It's not all or nothing despite forced backdoors.
So, you basically have to believe the US-based company you trust won't take 8-9 digit bribe, will accept bankruptcy, and/or has people who will do time for your privacy. I don't trust anybody running for-profit companies to do that except for maybe Levison. Even he might change after weighing damage he received vs probably no benefit of principled stand. Maybe he'll stay in the fight, too. Who knows. I do know Cloudfare has financial incentives to take massive investments and/or avoid massive losses. Might work against users at some point.
To be clear, Im a big fan of Cloudfare. They're awesome. There's just upper limit of trust since they're profit-motivated operating in a quasi-police state (ie a Dual State).
"All of these involves cloudflare violating terms of service they've made to Mozilla."
Terms of service don't overrule federal law or court orders. That's assuming they'll turn down money. RSA told customers they were buying crypto with no mention of backdoors. Yet, they put one in for about $30 million.
So, a company might willingly violate ToS for a pile of cash or unwillingly do it via legal coercion that comes with secrecy order. Leaks indicated most took the bribes. Many more bribes or coercions might have happened since. So, we should just assume its true with companies in surveillance states with other security practices designed with that assumption baked in.
Also, it might not even matter if one isnt doing anything over those connections that's illegal. The backdoor becomes something probable but irrelevant for those users. From there, Cloudfare protdcts them from relevant-to-them threats like DDOS or delays causing lost sales.
Currently, the provider could read the SNI value from the request, but work is done to encrypt that as well. This would allow them to see which Hostnamen was requested, but they cannot peek into the actual transmission (which is incidentally how domain fronting works: announce a different SNI than the actual requests Host header)
> The whole point of HTTPS and DNS-over-HTTPS is to not share any data at all with your provider. It’s not entirely working right now due to SNI being plaintext, but work is being done on that, too. So that’s really not a good argument.
If that was the whole point of https then we wouldn't have plaintext SNI. I can't even begin to understand why you think that there being a draft of an SNI encryption standard makes it 'really not a good argument'.
Originally, HTTPS required a dedicated IP address (or at least a dedicated IP/Port pair) for the server. SNI is a tack-on on TLS to fix that, so that TLS can be deployed more widely, allowing to encrypt traffic that was plaintext before. Encrypted SNI is a tack-on to fix that SNI needs to transmitted in plaintext. So yes, the design goal of HTTPS is to hide as much information from all intermediaries as possible. It’s just that you can’t fix everything at once, so gradual improvements are made.
Well, I can't get behind saying that hiding the site your visiting from your provider is the "whole point" of https when it specifically doesn't do that. I mean, we both understand what https is aiming to do in general, and I assume you aren't suggesting that https has been an complete failure since SNI was introduced.
However, admittedly I'm just reacting to you using the term "whole point" in conjunction with something it's failing to do.
I’m not suggesting https is a complete failure. I’m saying that HTTPS hasn’t yet achieved all that it intended to cover. It does the best it can given current real world constraints. That requires tradeoffs. But work is done to improve the situation and I’m generally happy for every feature that pushes the needle in the right direction.
So.. in some future Mozilla might select a default DNS provider on your behalf.
Did you consider the upside?
Mozilla can negotiate on your behalf. Mozilla can obtain favorable terms of service, concessions in privacy, third-party reviews. Things you would never be able to negotiate for.
If you think of Mozilla as negotiating on your behalf, they have motive to protect you, and they have the leverage to get concessions from 3rd party vendors.
Think of Mozilla as using the collective bargaining power of it's user-base to get favorable terms. This could be a game changer.
This replaces decentralised with centralised in the hope it would be a good idea if the choice is right. I'm sceptical, if nothing else because it would be easier to compromise or DoS one target than a lot of individual DNS providers.
> The article doesn't suggest there's something sneaky going on.
The article headline is "Mozilla's new DNS resolution is dangerous", so I guess you are right in saying they are not "suggesting", because they are down right accusing Mozilla of being sneaky.
It's important to understand the advantages of HTTPS via other protocols or custom crypto:
* HTTPS stacks are battle tested and there are multiple of them. Browsers in particular already ship a heavily maintained one that performs great, so using DNS on top of it gets all those benefits. Because there are multiple stacks the risk of people settling on a monoculture is a lot lower.
* People running a DNS resolver likely have the ability to run a good HTTPS server already, including having certs ready to go. Likewise, there are a bunch of battle tested httpd implementations out there and good https stacks to go with them.
* Proxies, reverse proxies, caching, etc are all well understood for HTTPS
* HTTPS2 has transport compression all figured out, so if you turn that on (which is 'free' once your server+client both support it) you're getting compression for free. HTTPS2 also supports multiple channels so if one request is pending you can still kick off another one over the same socket.
* Any debugging tools you can use with HTTPS can be used with DNS.
It's possible for a raw DNS protocol, or DNS+TLS, to pick up all of these benefits but DNS-over-HTTPS gets them almost entirely for free.
fwiw, web proxies over HTTPS2 are great too. The performance is great even over long distances because of the multiple channels and compression features.
You forgot the more pragmatic reason: middleboxes. HTTPS works everywhere, and introducing a new(2 years old) protocol (DNS over TLS) working on a new port (853) is a sure way to make sure it does not work in many places.
That mostly applies to corporate environments which already want to use their own resolvers anyway. For most people DNS over dTLS should work fine and if anything should be implemented on the OS level.
Your browser is not special, everything could benefit from secure DNS.
DNS over HTTPS is immune to amplification attacks.
If the alternative to DNS over HTTPS is a DNS-over-TLS resolver being run by a company without a website (???) then I guess that's easier than DNS-over-HTTPS. Are you really going to use a resolver run by a mysterious nobody?
There are probably more than a dozen HTTP stacks being widely used in production. It's not remotely a monoculture.
> Is there anything left, that's not on HTTP? Maybe NTP.
OpenNTPD also uses HTTPS (TLS, technically) by default [0].
Fortunately, they aren't yet trying to tunnel actual NTP packets over HTTP or anything like that, just using the information in the "Date: " header as a sanity check.
HTTPS gives you the packet ordering costs of TCP and the handshake costs of TLS.
With an SSH-like key setup - i.e. just getting the server's pubkey on first use and rolling it over when it advertises a new one - you could asymmetrically encrypt every request in a single UDP packet and thus gain the same security and lower 99'tile latency.
I support this but it has its downsides, for example flixbus blocks YouTube on their free WiFi. I think they have all the rights to do it as some site are heavier to support than others and they might be forced to shut it off if it became common
(Also a lot of people don't have earphones on them an being beside someone watching "funny" YouTube videos at 3am is torture (end of personal rant...))
that would mean that if many people used youtube they would all have terrible speed, which would make their wifi look of bad quality.
The primary purpose of their on board wifi is to buy tickets and check connections. In this case video streaming might really be more expensive than necessary
I mean limiting per-user bandwidth. So if you try to watch youtube on your personal 1Mb slice, good luck, but you won't drag down anyone else, and for the stated goals of buying tickets and such it's fine.
DNS over HTTPS might or might not be a great idea; but I'm critical whether centralised is better than the current decentralised approach. You're putting all your eggs in one basket, which might become an exceedingly interesting target.
The article provides no source for this assertion and this Mozilla blog post is pretty clear that DNS-over-HTTPS is off by default and defaults to CF if you enable it or are part of the shield study (which requires nightly and opt-in to shield studies in the first place) https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...
If this is true, then I'm okay with the feature being available if it is opt-in. Although I generally think this is a concern better left outside of the particular browser I'm using. If I want to route DNS queries through a third party then I'd like to do that for all my network traffic, not just my browser.
But that’s a different argument you’re making. For many people, routing the browsers DNS via a secure channel is a substantial improvement. You’re still free to route all your network DNS via DoH, there’s software for that. But until DoH is the operating systems default (or at least a non-expert option), this can be a viable improvement.
Yes. If it's opt-in, then I can certainly live with it and I understand why people might use it. I'm just pointing out that features like these, while well intentioned, still add bloat to the browser. Sometimes saying no to feature inclusion is the right thing to do in the long term even if it has a use in the short term. I'm a big believer of the Unix philosophy of do one thing and do it well.
Modern browser are basically OSes not by coincidence but because they are basically used as OS replacement. I think Tanenbaum (citation needed) wrote that an OS basically does two things: abstracting the HW and managing resources.
Browsers do the latter as much as an OS
I think you substantially overestimate the number of providers that behave ethically with regards to DNS and substantially underestimate how many people have shitty ISPs. You seem to have a very skewed view of how the number of internet users distributes across the world. Even in Europe, providers are not refraining from hijacking DNS and using DNS blocks for certain sites.
I think you substantially underestimate the number of networks that use split-horizon DNS for their functioning, and where hijacking the DNS is going to cause significant breakage.
No, but they do exist and specifically in this case (since they mention public wifi) pro users capable of configuring their system dns might not be the only target audience
I agree. I use DNSCrypt and route my requests through a different server each time.
That said, Joe User doesn't know how to setup any DNS server. Even going into Window's Control Panel gets Joe User anxious. Joe User doesn't care enough about privacy to learn how to set it up system wide. And for Joe User this would cover 99% of his internet usage.
The feature is opt-in. Firefox will use your system configured DNS servers unless you explicitly enable DOH. In that case you can still change Cloudfare for some other server if you’d like.
It bloody is. Egregiously so. If they are deviating from expected behaviour[1] they should obtain informed consent and even then it's unethical. Half of Mozilla is screaming decentralisation[2], the other is centralising the web as fast as they can. I still haven't forgiven Linux Mint for similar shenanigans[3].
[1] Users understand instinctively the principle behind reverse dns lookup. If ISPs can resolve at least portion of domain names then it doesn't make sense to then introduce another completely random third party that isn't strictly necessary for the process.
There's nothing sneaky going on here; which the article seems to imply.
Currently there is no UI to configure any of this yet (other than about:config) but you can trivially select any DNS provider that implements this in the same place where you turn this on. The relevant setting is network.trr.uri. Also, you need to opt in to this to turn it on so you'd be reviewing this setting as well. Also you can configure how this is used, how and when it falls back to normal DNS, etc.
You can run your own server if you want; or use the one from your provider if/when they implement this. For obvious reasons, there are not a lot of usable servers yet but it seems Google has implemented this as well. So I assume they plan to roll this out for Chrome at some point.
The premise of this article seems to be that you should trust your provider to do DNS and do it well. I'm sorry to say but for the vast majority of providers I have experience with the opposite is the case. I've had providers redirect dns failures to advertising pages in the past, shitty performance (600 ms or worse), and generally trying to rip me off with bad network infrastructure related outages while charging me a premium for bandwidth clearly not delivered via obviously very congested infrastructure. I have no reason whatsoever to trust them, at all. The less they can learn from my traffic the better.