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.
> My local ISP seems more trustworthy to me than a big US-based corporate which acts under the guise of a selfless privacy rights defender.
I have never trusted any local ISP. They’re commonly expressly allowed by law to share roughly whatever they like about you†, and they are known to do so.
Cloudflare has at least promised not to be evil, and is to be audited annually concerning it. If they desire to be evil I have no doubt they could wangle it, but I still trust them way more than I trust any ISP, because they’re already known to be evil under these definitions.
----
† (This is a gross simplification, but it’s broadly true enough in most countries.)
> (This is a gross simplification, but it’s broadly true enough in most countries.)
Seems like you forget Europe and e.g. GDPR.
It would be a big no-no in Denmark: My bank has one division for normal accounts and another for mastercard. The 2 divisions are separate companies, so I have to sign a paper to allow the MasterCard division to know about my normal account.
So Danes have no hesitation giving out personal information as they know it’s protected by law. “We don’t sell your info” is redundant in Denmark.
I wish that was the case. TDC (the largest danish telco) actually sold information about mobile users, including roaming users to VisitAarhus. Specifically, it was data about the locations of mobile users.
Telia did the same thing in Sweden some years ago. There are however ISPs who have a business model based on them having a very high profile in personal integrity politics (like Bahnhof), which I would feel more comfortable with thanany other DNSs
By wouldn’t you expect Bahnhof to offer a DoH-capable resolver for its customers then, that you could use in FF if you choose to enable the feature once it’s out of the experimental phase?
As a user whose trust has already been broken by both ISPs and governments, I see no drawback in participating as a user in this public experiment. What you describe as a drawback is a privacy improvement for me.
The DNS implementation used by every non-Tor user around the world today is already subject to warrantless spying by every ISP and government in the world, due to the property known as “cleartext”. If you opt-in to the Cloudflare trial, you are only at risk of warrantless spying by Cloudflare — rather than every ISP — and the US government — rather than every government.
My cellular ISP sells my DNS queries to advertising networks, and my home ISP is wiretapped warrantlessly by the US government. This experiment decreases the chances of the resale of my personalized data to data warehouses and decreases the chances of success of warrantless wiretapping by my government.
I envy those of you that believe you can trust your ISPs and governments.
And lets not forget that their CEO will arbitrarily censor and stop serving people he doesn't like. He's done it before. He'll do it again. Cloudflare has already lost my trust.
But he does and does. And now in the Perfect 10 lawsuit against your company it's biting you in the ass. Now you have to censor everything. Good going.
Cloudflare has already received NSLs. Once they provide both encrypted DNS and TLS-termination for a good chunk of the internet they'll become a juicy target for the three letter agencies and you might not know about it for years.
If you don't live in the US a local ISP might be a lesser evil and I wonder why mozilla should make that tradeoff for everyone.
Sure, some jurisdictions might be worse than the US and TRR might be a win there. But for some it's worse. So we shouldn't pretend it's a one-size-fits all solution.
I live in Australia; ISPs are basically all big entities, altogether unworthy of trust. The US is broadly similar. In both countries, you do get some obscure tiny ISPs, but they’re fairly rare overall.
I’ve also spent time in India with a small ISP, and I hated their DNS: they actively intercepted all DNS and replaced it with their own OpenDNS arrangement, involving the horrible NXDOMAIN replacement that was still a thing at the time, and in such a way that you couldn’t opt out of it! I don’t know how trustworthy they might or might not have been (I didn’t personally know them), but I do know that I loathed their technical decisions and would fain have bypassed them.
I get the point. If your ISP is also not trustworthy, the situation probably does not change much for you. Then again, maybe the right solution is to look at how to get back trustworthy ISPs.
Which is a goal to strive for as well however this endeavor is still valid as the client can be mobile and transient across ISPs. So until you can trust all Is as you might come into contact with, having a secure and hardened client is the better of the two.
There are (privacy) pro's and con's to having a small(-ish) ISP. 1: you have a payment relation with your ISP so your identity is 100% known. 2: Operators you know personally might turn against you, as it happens between people.
I use Swisscom (larger ISP here in Switzerland, both for mobile & home connectivity) but damn if I do not encrypt /hide as much traffic (DNS first) as possible to prevent exactly them from being able to see exactly what I do.
I have worked for far larger providers and I have personally investigated 10's of cases where a "roque" operator has fired for "abusing" access to very privacy sensitive data (being it internet access or mobile phone locations etc). As [most of the time|always] in these cases, the offender gets offered a decent exit to prevent (public exposure via) lawsuits so little gets known to the outside world.
In the end it is up to you, but my advice would always be: do not put all your eggs in one basket.
Speaking for the US now (this is an outside view) but to me it looks like institutions such as the CIA or the NSA are indeed seen as evil by the majority of the public. Now, both the NSA and the CIA would mean nothing in the medium and long span of time if it weren’t for the power projected and often times actually exercised by the US military. As such, one can be forgiven for looking at the military as “bad”, if only for the fact that it “supports” bad institutions. Or, in other words, you cannot pick the “good guys” out of the military-industrial complex, to think otherwise is just self-delusion.
Indeed, all us US taxpayers and, more importantly, citizens are complicity with the myriad heinous crimes of our government. They do them in our name, with our money, and in most cases with our vote.
OK, but I hope that you don't propose vilanizing any support helping US taxpayers because of it, as it was the purpose of the analogy to explore that. Are hospitals evil for providing healtcare to US citizens who are enabling NSA?
I don't really care about "promises" and contracts made between faceless corporations. I have no reason to trust Cloudflare or modern Mozilla, neither have I a reason to believe Mozilla would litigate against a breach of contract publicly instead of settling privately and secretly to prevent public outrage.
It's not a ISP vs Cloudflare issue though, the ISP will know where you are connecting to anyway...
This is such a toxic decision by Mozilla, but I'm not surprised since they have been leaking customer data to other companies (Google) that threw money at them in the past too.
but your ISP will still be able to see all your connections even if you don't use its DNS servers unless you use a VPN... this just spreads the information to a third party.
Downvote me all you want, but domain names are still being sent to the ISP unencrypted, as of TLS 1.3... so it doesn't matter who processes your DNS queries, your ISP still knows everything about which sites you are accessing... but anyways, bare IP addresses still reveal a lot (metadata)
wrt esni the anonymity pool is definitely the set of content that can share the same address pool. In a world with lots of CDNS (and several multi-CDN switching services) this covers a huge amount of content - but I agree - not everything.
If you think about the best/worst case scenario, would you be happy if one CDN would deliver everything? I think that we would be in a worst situation... ideally, I think that everyone would have their own servers and that your ISP would not even be able to see which IP addresses you are talking too (completely decentralized)
3. The article doesn't talk about how your ISP can use DNS to censor your result - very common, for example, in a country like India where the court orders certain sites taken down. Mozilla's DOH solves this.
Can you point to a Mozilla announcement that says they'll turn on DOH by default in a regular non-experimental non-nightly release?
This is what Mozilla says in their DOH blog:
Our second effort focuses on building a default configuration for DoH servers that puts privacy first.
We are running a shield study where some Nightly users will participate in one or more experiments to help us build out a secure, cloud-based service that handles DoH requests. All Nightly users will receive an in-product notification about these studies.
Cloudflare is our partner for these experiments. When a shield study is active, Nightly Firefox will automatically use Cloudflare’s secure DNS over HTTPS service (though we aren’t using the famous 1.1.1.1 address). The first study will test whether DoH’s performance is up to the task.
"We’d like to turn this on as the default for all of our users. We believe that every one of our users deserves this privacy and security, no matter if they understand DNS leaks or not."
Manually setting static resolvers is not adequate in many scenarios.
For example, when the user roams among several networks, and each of them has split-horizon DNS, the user is not going to re-set their setting after connecting to each specific network. Throw in VPN connections and their DNS settings, and you have quite a problem at hand.
There's a reason why DNS settings are traditionally set system-wide via DHCP, not statically. This is a step backwards.
Mozilla has stated plans to eventually turn it on by default[2] but I have yet to see any timeline or details of what the default config will actually be. Your article seems to assert that it will be on by default in FF62, where did Mozilla ever say this? Everything I have read seems to indicate that FF62 is just adding support, which is off by default, and requires a change to about:config to enable in the first place.
You're operating under the assumption that if this is turned on by default in the future, everything will go to CloudFlare.
While CloudFlare is being used for the opt-in study, you have no evidence that they will be used in any on-by-default scenario. Nor do you have any evidence that only a single DoH provider will be used globally.
I use internal DNS for stuff I'm running at home (e.g., a NAS, Home Assistant, etc). I don't want to go back to the bad old days of having to remember what IP addresses go with what service.
My girlfriend is not going to like it when Pi-Hole magically stops working because Firefox doesn't respect the DNS settings that are served by DHCP.
My employer uses internal DNS for internal services. The helpdesk is going to have a fun time as Firefoxes across the organization get updated. It also doesn't help that a large number of users are BYOD users, so enforcing certain Firefox settings is a no-go.
Sure, there's instructions to fix it, but it should never be broken like this in the first place.
EDIT:
The article has been updated - it now shows a screenshot from Mozilla's blog[0] which says:
> We’ll use the default resolver, as we do now, but we’ll also send the request to Cloudflare’s DoH resolver. Then we’ll compare the two to make sure that everything is working as we expect.
Cloudflare is going to have a huge list of internal stuff used by Firefox Nightly users, and Mozilla is going to have huge insights into how many people use things like Pi-Hole, internal DNS servers, split DNS servers (e.g., BIND Views), etc. And they're going to be analyzing this data in order to determine how well DNS-over-HTTPS works.
I'm not sure if this is better or worse than I initially thought it was.
First, I have to say that I love cloudflare, but the last thing we need is the centralization of all our DNS resolution to them. Please Mozilla, don't give anyone too much power.
And if DNS over HTTPS is the way to go (which might be), give the user a choice. There are 3 public resolvers already offering DNS over HTTPS:
Google[1] (was the first one to support it)
CloudFlare[2]
CleanBrowsing[3] (for security and/or adult filtering)
And hopefully Quad9 will join the list soon. I hope this doesn't become a "search engine" war that the company that pays more becomes the chosen DNS. Please Mozilla, don't do that.
The expected common deployment mode is soft fallback - using traditional DNS if connections cannot be made via the DoH resolved address. Captive portal provides the most common use case.
There is a hard failure mode available that you can use for better security if you're in a vanilla Internet environment - but we don't see a way to broadly offer that choice other than in technical documentation.
Thanks for answering questions in this thread. This makes a lot more sense - so LAN-only names would still resolve then.
This still seems like it could cause problems in certain circumstances, e.g.:
- The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole)
- An internal host also happens to resolve on the external DNS, though with a different IP. E.g., a company could have its public DNS set to a catchall entry *.company.com, but at the same time could have dev.company.com set to a special IP inside the LAN. This setup seems also required if you want to use Let's Encrypt internally.
Those scenarios seem difficult to manage, because they are potentially indistinguishable from attacks. Do you have any solution for that?
The most important attribute of DoH is, imo, authentication with the resolver. The browser has a terrible time with 3rd parties messing with the DNS stream. DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to.
> - The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole)
The right answer, imo, is that the pihole implements doh and firefox is configured to use it directly. The reoslver is authenticated and you're sure you're using the policy you want. A quick search indicates some interest in doing just that - I know stubby is working on doh support.
in the interim of course, you can just disable DoH and hope that your unauthenticated udp makes it to the pihole and back in tact :) - there's never going to be a lock in.
> An internal host also happens to resolve on the external DNS, though with a different IP. E.g., a company could have its public DNS set to a catchall entry *.company.com, but at the same time could have dev.company.com set to a special IP
so far as we can tell, this doesn't seem to be a significant pattern with http content.. at least not to the point where both split horizon addresses correctly handshake from each side (defeating the fallback logic). I suspect this has to do with http caching not working very well in such a setup either. This is exactly what we're looking at error rates trying to determine, but the prevalence of other open resolvers like quad 8 seems to have really reduced the frequency of this kind of thing.
There are certainly some dev environments at the tail that will require manual config.. but for the most part those environments already have a bunch of manual config so this isn't a huge leap to do.
> DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to. [...] The right answer, imo, is that the pihole implements doh and firefox is configured to use it directly.
This is a worthwhile goal. However, the current UI heavily discourages changing the preset resolver (you have to skip through a warning page, know the correct properties, etc). Do you have any plans for a more acessible UI to set resolvers?
Another point, I think, is that DoH endpoints could be abused by malicious (non-browser) software to hide its communication endpoints.
E.g., when public DoH servers are common and encrypted SNI is operational, a mobile app or IoT device could completely hide with which hosts it is communicating - with no option for the user to override. This doesn't seem to be in the interest of privacy or transparency of data use.
Similarly, a trojan could use a public DoH server as a secure channel to get C&C server addresses, without the name of the C&C server ever getting exposed - or it might even directly obtain commands through it, if the commands can be embedded in DNS records.
Hopefully it caches the domains that it found to be internal (not just the records), or there is going to be a lot of data leakage of internal records. There is already way too much of that, given how most folks have their resolvers configured poorly, but this would only make it worse.
Firefox, out of the box, is going to be perfectly useless to me.
At home, I have an internal DNS resolver which is used for internal stuff (e.g., Home Assistant, a friendly name for my NAS, etc). This will be broken. Likewise, I've got Pi-Hole set up for my girlfriend, but that's going to stop working as soon as her Firefox updates itself to this version.
At work, we have an internal DNS resolver for obvious reasons. All of the users who use Firefox will suddenly be unable to access internal sites. That's going to be a fun time for the helpdesk as 3000+ staff start receiving updates.
I know it can be turned off, but having to track down a hidden setting to make the browser actually function correctly is insane.
This isn’t enabled by default on any versions of Firefox and Mozilla does not have a timeline for enabling this by default on any future versions of Firefox.
I think as far as browsers are concerned, there are no private DNS names anymore for a good while already - either everyone on the internet knows your DNS or it doesn't exist.
See the similar problem with TLS certificates...
(edit) Ok, that was indeed put more dramatically than necessary. My point is that private DNS names seem to be heavily discouraged by browsers default configurations.
You can change both the DNS resolver as well as install custom CAs - however, this has to be done again for each client. If you want to have your sites visited by clients that you don't administrate, you're out of luck.
(warning - rant follows) The direction browser vendors would like the ecosystem to move also seems quite clear to me - there is a strong push to get everyone on HTTPS, at the same time CAs are themselves increasingly regulated by browser vendors and cannot hand out certificates for IPs and private DNS names anymore. Now the next step seems to be DNS. If that is not a platformisation of the web, I don't know what is.
Perhaps if you only work for small organisations. Medium to large organisations tend to handle these issues relatively smoothly, with company computers and devices usually having their root CA pre-loaded into the trust store - or requiring users to do it themselves in order to connect to the intranet.
Just because you don't see it, doesn't mean its not there!
Can only heavily disagree with this one. The reason why BIND has views is because bigger organisation (like universities) employ different views depending on whether you are internal or external.
But this is the exact point. With DoH active by default (and no custom configuration set), every instance of Firefox will appear to be querying your DNS from outside, no matter if the machine is inside the LAN or not.
Your home router will. However, as the article made clear, you won't be able to open that site in Firefox.
Even if you were, you won't be able to get a public TLS certificate for that site, making you unable to serve the site as HTTPS and locking you out of many current and all(!) futue JS and CSS features.
Yes, you can solve both problems by installing overrides. However, this has to be done separately for every client that you want to use and (potentially) for every app that you want to connect to.
If you want to make an intranet-only web page that "just works" with off-the-shelf clients, you'll have to stick to public domain names.
Maybe all the users that turn TRR on in the first place? It’s default off and you need to enable it in the expert configuration menu. I don’t expect it to be enabled by default without a reasonable config UI.
The article states that DoH will become on-by-default in september.
In general, I find it highly unlikely that it will stay off-by-default forever, because there is no way to have any meaningful adoption of it as an expert-only feature.
Nothing in Mozilla’s communication even hints at DoH becoming default on any time in the nearer future. I’m certain Mozilla would like encrypted DNS by default, but not at all cost. It will probably land as a generally available feature in September, but still default to off and still be behind about:config. There are many expert features hidden in about:config that might never become default or only after a substantial shakedown period. Third party isolation, for example. So it would not entirely surprise me if DoH would remain an expert feature for a long time. And I’m certain it won’t become default on without a very clear config UI. Messing with name resolution has massive impact on a lot of setups.
My home router will. My browser will also open the site. My browser might not necessarily be Firefox, though.
For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed, so whoever controls that domain, can make certs for its resources. If you do that at home, it is no problem to make your own CA and use it for your home resources. It is just few commands with openssl, which you have already installed anyway.
> If you want to make an intranet-only web page that "just works" with off-the-shelf clients, you'll have to stick to public domain names.
That's not true at all, see the previous paragraph.
> For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed
Thanks for that info, I wasn't aware of that. However, to my knowledge, Firefox doesn't use the OS trust store but its own. So for clients using Firefox, you'd still have to install the cert, wouldn't you?
For the ESR release, you can use Group policy (Windows only) or policies.json (all systems) to make it accept the system cert store.
For all releases, you can make the process of joining the domain to also include installing the cert into Firefox's store. For example, the Redhat's ipa-client-install does install the certificate into the Firefox store by default.
> You can change both the DNS resolver as well as install custom CAs - however, this has to be done again for each client.
That's exactly what Active Directory and FreeIPA do. They have their own CA and once you join the respective domain, you will get the CA cert installed. Hence, using the internal resources is not a problem.
There is and never will be a good reason to publish to the world, what your _kdc._tcp.yourcorp.com is.
Many already run their own resolvers, so providing DNS-over-HTTPS proxy is not a problem.
What is THE problem, is configuring the browser. No one is going to reconfigure their browser after each connection to a different network. There's a reason why we moved from static configuration towards DHCP, which can configure network-specific settings. DNS is a network-specific setting, and Mozilla is breaking it.
Split horizon was always a bad hack, there has always been alternatives. DoH could be used on the default DNS servers too, there is value of encrypted DNS on LAN as well.
> Split horizon was always a bad hack, there has always been alternatives.
I always see this repeated as a mantra, but never it's rationale. No company is going to advertise their internal infrastructure needlessly. There's no upside in the world knowing that your _kdc._tcp.company.com is 192.168.10.20; but there are downsides.
> DoH could be used on the default DNS servers too, there is value of encrypted DNS on LAN as well.
Sure, but hardcoding or statically-configuring the value is not the way. LANs need to have their DHCP tags respected. If one of them is "use this URL for DoH-server", that's fine.
Many corporations will choose to run their own resolvers for internal services.
Home/small business router vendors already include DNS resolvers on the boxes they sell which work to automatically provide hostnames for addresses that they've served up with DHCP.
You don't need DoH for that. Just use a VPN and configure it to replace your host's resolver as long as it is up.
Another advantage of using standard UDP-based DNS over a UDP-based VPN is that it can reorder packets in flight, so it should have lower latency than anything TCP-based.
The counterpoint is that traditional DNS has horrendous loss recovery and basically no congestion control and these things definitely benefit DoH at the tail.
QUIC will let us have it both ways (and as QUIC has an HTTP definition, its basically a free upgrade for DoH).
> And your ISP knows where you connect to anyways. So the data or information generated by their DNS server provides no additional information to them.
This is not correct. Your ISP only knows what IP you are connecting to and that is not enough in general. E.g. Cloudflare.
and the internet becomes sufficiently centralised that you only access a few IP addresses behind which most services are hosted. In other words, we can either
a) trust our ISP with DNS queries and IP addresses which fairly uniquely identify services or
b) trust Cloudflare with DNS queries and our ISP with IP addresses which fairly uniquely identify services or
c) move everything "behind Cloudflare" and solely trust Cloudflare
Given that I can cancel my ISP’s contract, I can hold them accountable if they spew my data into the internet and I have no idea who Cloudflare is or what their aims are, I’d much prefer a) over c). b) is just worse than a) or c).
Great! And you can already choose to do so. But it seems pretty likely that Firefox will be making that decision on behalf of all its users (except those with the wherewithal to know how to opt out), without effectively communicating the risks of that decision to them (based upon their communication about this feature so far).
It’s currently an expert feature that’s off by default. There is documentation in the wiki and a blog post on the nightly news blog for those that are interested in turning it on. It’s quite the opposite of opt-out. It’s opt-in for the technical inclined. What would your expected level of communication be?
I host my own DNS resolver on a dedicated server, Firefox hijacking my DNS traffic without telling me is definitely not an improvement. It can be a nice feature in some situations but having it activated by default without explicit consent should be a big no-no.
I hate this mentality of "our users are complete idiots and we know what's good for them" (I call it the "Gnome" mentality).
There are many public DNS providers those promise to not logs DNS queries. I don't know precisely but if Mozilla forces user to use Cloudflare DNS is the deal breaker.
They don’t. It’s the default if you choose to enable the feature, but there are other compatible DNS providers, pick any that suits you (or just don’t enable the feature and keep doing what you’re doing now)
Well, you have to trust some third party. Personally, I think Cloudflare's DNS is pretty trustworthy based on what we know. It's WAY better than sending unencrypted DNS requests to arbitrary network-dependent third parties, in my opinion.
If you gravely fear Cloudflare for some reason, Google also provides a DNS over HTTPS server, along with a couple others. You can probably set Firefox to use that.
But if we we're OK treating this as insensitive data not needing encryption before, worrying about trusting third parties is not even the beginning of the problem.
There are many countries where ISPs are obliged by law to spy on users, and retain logs for many years. DNS manipulation also used as a cheap censorship mechanism. So Cloudflare easily can be a better option for hundreds of millions if not billions of people. As a rule, local actors present way more serious threat compared to US agencies for majority of the planet's population. That said, Mozilla, of course, must be very transparent with such big changes, and explain them to users not using just "more secure" wording.
You are refuting the statement I never made. There's no such thing as general threat. So who's data? If you are Julian Assange you should be afraid of US spying agencies, but if you are an Uzbekistani dissident it's your gov't repressive machine you should care about, and tracking possibilities of your direct adversary will be diminished with the discussed Mozilla's move. If you are an average Joe in a small town you may find it safer to trust faraway commercial entity rather then your neighbor's nephew who works in a local ISP.
I use Cloudflare's resolver, but I actually agree with this. I don't want every device in my local network ignoring my Pi hole or my custom DNS entries, I don't want the device of everyone in my country being subject to surveillance requests from the NSA (and Cloudflare is legally (if you call warrantless wiretaps legal) required to comply), and I don't like the centralization this brings.
If I recall correctly, this also breaks geographical-based DNS resolution?
> I don't want the device of everyone in my country being subject to surveillance requests from the NSA (and Cloudflare is legally (if you call warrantless wiretaps legal) required to comply), and I don't like the centralization this brings.
Agreed that this introduces additional centralization. Maybe Mozilla could work to with other third parties in different jurisdictions to see if there's interest to spin up additional DOH servers. That said, if your threat model includes the NSA then this would probably be far from sufficient.
As always, it's not "the NSA is targeting me specifically", it's "they're doing dragnet surveillance for potentially 'interesting' data and who knows how they'll choose to harass me".
There is literally no single country in the world I would like my data sent to than the US. Even China is preferable.
That depends. Cloudflare probably (did not check) uses anycast and thus their DNS servers are actually in the specfic region. This however does not change the problem of the legal authority still being in the US, as you pointed out.
Great, all your data is stored for 24 hours and then collected in "anonymised" form for further processing and "internal research"! Also no mention of penalties, either for Cloudflare as a company or the responsible employees (starting with the CEO) in case of a violation. And no notice period of any time should Cloudflare decide to change those terms and have thousands of browsers still pointed at its resolvers.
Why would this make Cloudflare appear remotely trustworthy?
It's a legally binding contract between Cloudflare and Mozilla. If Cloudflare were to violate it, Mozilla could sue and a judge would determine the penalties for Cloudflare. There should be some rough guidelines written into law as well.
And we're definitely not talking about small amounts.
Cloudflare violating it would result in Mozilla violating the privacy of millions, which can be interpreted as significant damages to the citizens. They're also both situated in California, so privacy will be valued by a judge. Given Mozilla's public image as a privacy-friendly organization, they could also push charges for damaging that image.
That penalty + the damage to Cloudflare's own reputation, I cannot imagine they would survive.
Data from temporary logs will be moved (anonymized) to permanent logs. For me this reads as: once it is there, it is not your data anymore, not from Cloudflare Resolver for Firefox and not PII, so we can do ~whatever we wish.
IANAL but it looks like extreme weasel wording (and not even remotely GDPR compliant), there is nothing to violate.
Nothing against Cloudflare, but I don’t think it is good in general for the Internet that they are getting so critical.
For them this sounds like a good deal (is money involved here?). Having more control of DNS should mean they can provide better service for their customers.
> For them this sounds like a good deal (is money involved here?).
There is a lot of money involved. When you resolve DNS only over Cloudflare, all Cloudflare sites will have a much lower DNS resolution time than any domain that is not hosted by CF's DNS service. CF can also do geo DNS more efficiently, potentially saving millions in edge nodes.
Agree - cloudflare probably does a good job here, but again: centralisation is making the Internet weaker. Also hands even more control into one entity's hands
Cloudflare shows how broken the internet is. For example, imagine a world where you would clearly see that your computer or toaster were used in a botnet because it showed up in your billing. DDoS wouldn’t be $5 anymore.
Saying Cloudflare ruins the decentralized internet got the events out of order.
I was thinking about this issue. Once this feature is on by default, all Firefox DNS query goes through the Cloudflare, a for-profit company which resides on US whose government is infamous for spying everything.
My conclusion is, what's the difference?
Currently, Cloudflare is one of the major CDN in the world and most traffics goes through them.
Even worse, by it's nature, Cloudflare and most of the CDNs are practically doing MITM attack so they can cache the data. For that, HTTPS isn't that secure the most browser vendor want us believe to be. The rise of CDN cause serious single point of failure but most of us don't worry about it like DNS.
To solve this problem, we need to invent completely decentralized new network that doesn't relies on the current Internet even at the physical layer. Probably fallback to the level such that we carry storage by foot or pickup dead drops.
I don't like the way Cloudflare is centralizing everything, but I would use Cloudflare any day over my ISP. Seriously, fuck my ISP.
I would support this feature on the condition that users are able to choose which DNS service to use by default, especially as more public DNS services begin to adopt DoH. Developers like us will also need the ability to use /etc/hosts or route queries to a local instance of dnsmasq.
Obviously there's a switch somewhere in about:config, because Firefox is also involved with the Tor project which requires the ability to route DNS queries through Tor. This switch should be accessible to the user, just like the choice of default search provider.
The internet has decentralized architecture underneath but the model is being abandoned because traffic volumes are too high for the naive decentralized architecture.
Today 60% of the global internet traffic goes trough CDN's. In 2021 it will be over 70% in 2021 (over 90% in North America). There is whole "internet cache" industry standing between clients and servers.
When you connect to some site in the internet, most of the data comes from some of these: Google CDN,,MaxCDN, Akamai, MS/Azure CDN, Limelight, EdgeCast, Amazon CDN, Coudfare,Rackspace, Incapsula, ...
The issue here is not decentralization vs centralization, it's about browser selecting something for a user as a default.
You cannot compare CDN with DNS which does not require high traffic volumes nor expensive servers.
The issue is pervasive laying of trust into "benevolent" third parties, CA's apparently are not enough and we now must have Trusted Recursive Resolvers, too. And it's more and more difficult to set up alternative infrastructure which does not rely on them.
I think it's a nice feature to have but it has to be opt-in, you can't set the precedent that it's fine for a web browser to hijack your web traffic, even if it's for a good reason.
To be honest I think it's great news. I would much rather trust Cloudflare to handle my (encrypted) DNS than my ISP. I'm based in the U.K and there are very few ISPs that have private DNS - you often hear stories of (U.K) ISPs selling data out the backdoor to comply with things like the Investigatory Powers Act[1].
But besides Mozilla's efforts, I am careful not to browse anything political using a vanilla ISP. Anything sensitive is browsed with Tor for anonymity. I only use a VPN for routing traffic over hostile networks like public wifi hotspots / Starbucks wifi. A VPN is not inherently private but a VPN does have its uses, like for viewing geo-locked content (Like the 'This video is unavailable in your country' scenario).
As I understand it that's even the default choice, and CloudFlare is just the provider they're currently testing this with for those who do choose and do not configure their own provider.
So the default is that this is off. If and when that changes, the question that should be relevant is whether the majority of those users is better served with CloudFlare than their ISP, given their threat model.
I know my ISP is required by govt to log all meta data (websites, IPs, email headers). If I'm not using a VPN, it's all logged. Encrypted SNI is coming, but without encrypted DNS it's all still logged. So it seems like a net win, even if cloudflare is logging everything.
That would work. DoH is "just" a replacement for UDP in this context. However when Mozilla changes the default to DoH of Cloudflare, you will need to manually change all firefox installations.
This feature will break dns-based geo-lookup, so as a user I might get directed to services that are 130ms away from me instead of 1-5ms. For any client application, this will likely have strong negative effects on user experience.
It seems like you are right. On the company's pages I find "... Instead of doing this, Cloudflare will make the request from one of their own IP addresses near the user. This provides geolocation without tying it to a particular user. ".
Still, my concern is that this is no longer a function of the technology, but by a service that is maintained by one company, limited to the coverage that they provide in different parts of the world.
I think he forgot to write the part about how it is dangerous or not 'more secure in general' after explaining why it is for the average user who is likely to connect to any open wifi network without setting static DNS.
I don't understand why so many people are critical of people being wary about how a company deals with our data, especially one in Mozilla's position. Did all of you sleep through the past twenty years?
If they can MitM you to see your post, base64 will just draw more attention. Consider checking SSL fingerprints from trusted and untrusted locations instead.
I would also suggest browser addons that will alert you when SSL fingerprints change, but they don't work in FF any more, so you will have to do it manually understanding that they can swap out certs based on tcp packet size. You can also pin the cert, understanding you will have to update it if HN changes out their certs or they expire.
They cannot read HTTPS unless it is using TÜBİTAK certificate (all .gov.tr and some other .tr domains use this). There are more layers of censorship till central gateway, which is inferior to, but structurally more robust than GFWoC.
Just because what you're doing is private doesn't mean it's secure. Just because what you're doing is secure doesn't mean it's private.
No whistleblower should ever just expect that doing things the normal way is private or safe for them. If you wear a tinfoil hat, you need an entirely different operational language than typical users have, because your needs are totally different.
Privacy improves security for everybody. If an attacker can read all your DNS lookups then it's easier for them to target a spear-phishing attack against you.
Privacy may improve security, but usually not. It is a sometimes unintended consequence.
If I want to tell you a secret, I will bring you into a private room. Now we have privacy. If someone wants to listen in on our conversation, they will plant a bug in that room, or listen through the wall. To remain secure, I must add security countermeasures to prevent the bugs from transmitting, or extra noise to make being overheard difficult.
Your ISP's DNS might be more private, but if an attacker can poison your ISP's DNS cache (it has happened to me on my ISP) you won't be more secure. It's more secure to use a hardened DNS service, which is usually not local. But yes, this could be a minor privacy concern with a big enough attacker.
Just because you add privacy does not mean you added security. Just like because you add security does not mean you have privacy.
So please be honest about the motives for things like this. If you want more privacy, say so. Don't say it's a security problem when it's not.
If you don't trust local ISPs the solution is not to put your eggs into the cloudflare basket which could then be plundered by the NSA fox.
Instead tunnel all traffic to some rented box in a jurisdiction of your choice and then run your own DNS resolver either in your home network or on that box.
"We wrote in a previous version that "the next Mozilla patch in September" will enable DoH by default. We corrected that part as it is not clearly stated on Mozilla's blog, as can be seen in the screenshot below."
Think what is dangerous? Encrypted DNS? Choosing a DNS provider you don't like for an experimental feature because the support that feature? Trying to make the web safer and less creepy?
I think you have a fundamental misunderstanding of what is this experiment is configured the way it is and you're just being a Chicken Little.
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.