Firefox Enables DNS over HTTPS

This is good news:

Whenever you visit a website—even if it’s HTTPS enabled—the DNS query that converts the web address into an IP address that computers can read is usually unencrypted. DNS-over-HTTPS, or DoH, encrypts the request so that it can’t be intercepted or hijacked in order to send a user to a malicious site.

[…]

But the move is not without controversy. Last year, an internet industry group branded Mozilla an “internet villain” for pressing ahead the security feature. The trade group claimed it would make it harder to spot terrorist materials and child abuse imagery. But even some in the security community are split, amid warnings that it could make incident response and malware detection more difficult.

The move to enable DoH by default will no doubt face resistance, but browser makers have argued it’s not a technology that browser makers have shied away from. Firefox became the first browser to implement DoH—with others, like Chrome, Edge, and Opera—quickly following suit.

I think DoH is a great idea, and long overdue.

Slashdot thread. Tech details here. And here’s a good summary of the criticisms.

Tags: , , , , , , ,

Posted on February 25, 2020 at 9:15 AM • 61 Comments

Comments

WhiteN01se • February 25, 2020 9:37 AM

“Using a DoH implementation within an application: Some browsers have a built-in DoH implementation and can thus perform queries by bypassing the operating system’s DNS functionality. A drawback is that an application may not inform the user if it skips DoH querying, either by misconfiguration or lack of support for DoH.” (Wikipedia)

And that’s where it flies right out of the window. I decide what DNS is to be used (in this case: my piHole), not anybody else. Period.

tz • February 25, 2020 9:43 AM

One problem is login or click here for ToS bounce pages, but I’ve found that going to (http://)1.1.1.1 usually can bring them up. Otherwise some other fixed IP.

There’s also DNS-over-TLS which also works, but HTTPS adds a few things making it more efficient.

You still need to do “custom” for NextDNS in firefox if you want your account settings to be used (just add /123456/devid – account number, optional “device” string).

I like NextDNS because it has great analytics and configurable block, white, and blacklisting. I managed to shut off most invasiveness on my network security cameras, but they kept getting time from specific NTP sites (time.nist.gov, time.microsoft.com, time.apple.com) and I saw that in the NextDNS.io logs and analytics. And one Android app I used keeps wanting to talk to Facebook.

Curious • February 25, 2020 9:46 AM

I wonder, if one somehow simply relied on IP numbers directly for accessing a website, would that in theory negate any and all use of a DNS server?

Ken • February 25, 2020 9:51 AM

It’s a trust issue more than a security issue. I trust our locally managed DNS far more than I trust some browser vendor with an unknown agenda.

Peter A. • February 25, 2020 10:11 AM

@Ken: but your local DNS resolver has to go to the root and TLD and SLD and… all of this is seen by your upstream IP transport provider. Unless all DNS servers in the world implement DNS over TLS, having local resolver does not do much to solve trust issues with your ISP. I agree with you that using public resolver with encrypted traffic (either DoT or DoH) just moves your trust elsewhere.

I also have a local validating resolver (not all devices on my network are smart enough to check for errors) and I really don’t have an opinion if configuring it to go for data to some public resolver instead of allowing it to query all the way from the top is a better way to go or not.

allan • February 25, 2020 10:37 AM

We rely on our enterprise DNS to block sites that may be harmful to our employees.
We would have no control over the DoH server, and futhermore, no visibility to sites our employees vist (including java scripts enbedded within ‘legal’ or ‘approved’ sites. We disapprove of DoH for these reasons. I really wish there were an enterprise wide method to disable this ‘protocol.’
Sorry, Bruce, I really agree with almost everything you say but must take a stand against this.
Peace

ferritecore • February 25, 2020 10:43 AM

DNS over HTTPS, A good idea, more or less. I’d probably prefer DNS over a secure socket without wrapping it in HTTP, but whatever.

DNS resolution (or anything else) in an application bypassing established system services is as recipe for chaos. Different applications resolve differently?

Push for encrypted DNS in the system service. Then every application will benefit.

Frank • February 25, 2020 10:43 AM

Now using DNS over HTTPS on firefox (outside US!)

“Today, Firefox began the rollout of encrypted DNS over HTTPS (DoH) by default for US-based users. ..

If you’re outside of the US and would like to enable DoH, you’re welcome to do so by going to Settings, then General, then scroll down to Networking Settings and click the Settings button on the right. Here you can enable DNS over HTTPS by clicking, and a checkbox will appear. By default, this change will send your encrypted DNS requests to Cloudflare.”
https://blog.mozilla.org/press-uk/2020/02/25/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/

www • February 25, 2020 10:46 AM

It baffles me how security experts can support the move to DoH. Of course encrypted DNS requests would be great, but is inside the browser really the place for that? The idea is wonderful, but the implementation is not just sub-optimal, but harmful. The effort towards DoH would’ve been much better spent getting OS’s to support and default to DoT.

How would DoH affect other areas sorely lacking in DNS security, like IoT? If anything it will make it harder by duplicating effort. Or are we looking to run Firefox on ESP8266’s now?

WhiteN01se • February 25, 2020 10:48 AM

What – if i may – is the point of having DoH other than to override user’s DNS settings, potentially without user knowledge and consent?

Dr Blank • February 25, 2020 10:52 AM

@allan
I really wish there were an enterprise wide method to disable this ‘protocol.’

DNS over HTTPS can be disabled using group policy.

You would have to use the group policy templates provided by Mozilla. These templates provide the option “Configure DNS Over HTTPS” which can be set to disabled.

https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy-windows?redirectlocale=en-US&redirectslug=customizing-firefox-using-group-policy

Michael Leake • February 25, 2020 11:22 AM

I did not know where to put this, the latest ‘The Simpsons’ will humorously explain, completely how bitcoin and blockchain work

Kieran • February 25, 2020 11:24 AM

It looks like any using a DNS security product can disable this behaviour by setting up an A record for the canary domain, use-application-dns.net… but what’s to stop nosy ISPs (or other attackers) doing that?

Michaela Merz • February 25, 2020 12:04 PM

DOH is a pretty stupid idea. Name resolution should not be done on application level or we end up with each application deciding for itself which name server to use. It also forwards all of the resolution requests to a single source, with tons of possible bad implications. As the addresses within the data communication are not encrypted, our providers are aware of the data traffic anyway. DOH circumvents organizational settings and it may even ignore the hosts file. The fact the Mozilla enables it by default is IMHO ridiculous. As a security engineer, I am not happy with the (security) state of the classic DNS. But DOH is a step in the wrong direction. It creates more problems than it solves.

RealFakeNews • February 25, 2020 12:30 PM

Inside the browser is entirely the wrong place for this.

Busy now, so I’ll expand my thoughts later.

Mansour • February 25, 2020 12:50 PM

I guess in my 20 years of career in security, this is the first time I disagree with you Bruce 🙂 I don’t think this is a good news. Introducing DoH on Firefox yes is a very good news indeed, but Mozilla forcing it for users definitely is not.
DoH is not a silver bullet, but still a very good control. However in the absence of so many DNS providers supporting it, it just empowers privacy-monsters like Google; as they will now have access to a huge resource of DNS queries coming from people who even are not using Google products.
I know Mozilla is enabling DoH for Cloudflare servers, but that’s not much different.

VRK • February 25, 2020 1:18 PM

@Bruce Thanks. for most this just means it will be switched from mode 0 to mode 2, I suspect? Still a fail at times even if the sys and pipe admins are on board.

@WhiteN01se

an application may not inform the user if it skips DoH querying

Exactly. It seems DOH was neutered in favor of ADMIN forced dns since mozFF 70: no warning. Note: “network.dns.skipTRR-when-parental-control-enabled” in about:config, set false. Bizarre pref.

@Curious

*somehow* simply relied on IP numbers

was my question also, but as Peter [not so generically] said “just moves your trust elsewhere”, as I see it: Then you still trust routing. The upshot: BEATING FAKE is having a neck you can choke when you hand your 10¢ to the ferryman: marry a farmer, getOffTheGrid()

@allan your REGIME model has failed for anyone who… everyone.

@Dr Blank the post is oddly undated. I think firefox 70 caters to those having “parental issues”.

@Michaela

Agreed DNS is in a bad state, but the DOH patch seems… like a rung up the ladder for now. Truely HTTPS itself is broken without trusted dns. TORproject is a pretty successful patch too, but why are we kicking against the pricks like this? Loyalist saber rattling. Byte them, not the IETF.

“forwards all of the resolution requests to a single source, with tons of possible bad implications.”

Unless the network admin is a known “sympathizer” who fears ROI and SAM more than… selling you for beer money.

“addresses within the data communication are not encrypted, our providers are aware of the data traffic anyway”

It is odd that esni isn’t enabled when Mozilla, for example, goes to DOH mode 2 etc. But then neither DOH NOR ESNI are fully supported.

@all
I think it was the IETF that said

<

blockquote>”A client MUST NOT trust a DNS API server simply because it was discovered, or because the client was told to trust the DNS API server by an untrusted party.”<?blockquote>

whats a mother to do? I wear a swimsuit at the beach, and a door is on my bathroom too. Dang, what crime MUST I be hiding? EOF

Dr.Flay • February 25, 2020 1:24 PM

OK. So many people missing important points here.

1) Mozilla are not taking choice away. First you have the choice to switch it off, and next you have the choice to use your preferred DNS in the config if they provide DoH.

2) This is a temporary fix until the OS vendors have implemented their own replacements.
(even when they do I will continue using DNSCrypt).
As pointed out this is not something that individual programs should be doing or it will become its own security risk.
Microsoft have already started on their version.

3) HOSTS files will work with OS level DoH (when we get it).

4) DoH/DoT etc. are only a partial fix.
Currently no software has any way to show you DNSSec success, errors or failures since Firefox and Chrome dropped support that allowed extensions to show this. Even with an encrypted DNS you have no feedback or indication to show if there is a man-in-the-middle
Is your DNS using the expected key ? and same for the DNS of the site you are visiting ?
We have no indication that certs and IPs do not match.
Browsers try to warn about certs not matching the domain, but when the domain is correct but the IP is not, they could care less.
Encrypted is nice, but encrypted to the correct places is better.

5) For those that want OS, router or pihole level encrypted DNS with HOSTS blocking now, that has been available since DNSCrypt was available. It used to be DoT and/or DNSCrypt, but they added DoH a while back.
Its HOSTS handling is more flexible and powerful than standard OS implementation, allowing for forwarding and cloaking rules.
You can find cloudflare and quad9 in the DNSCrypt resolver list.
It can use as many DNS as you like and will opt for the fastest responding.

www • February 25, 2020 2:12 PM

@Dr.Flay: I think you’ll find that we’re not so much missing the points, as judging the damage done as (much) more than the gain.

  1. As all of infosec knows: defaults matter. A lot. DoH is a bad choice, and worse as a default.
  2. That does not excuse a “fix” in the wrong place, especially when it has this kind of detrimental effects. If anything the rollout of DoH will increase friction to adopting (proper) OS-level solutions. “But our DNS is already encrypted with DoH! derp“
  3. Irrelevant, because we don’t have that (yet).
  4. That’s an easily solvable logistics issue (not a technical problem) and no different with DoH.
  5. Same as 2.

Nothing you’ve said vindicates DoH in the least.

me • February 25, 2020 2:35 PM

@ALL
You are bassically complaining about “man in the middle attack stop working this is bad meh”

Well you are all wrong, doh enforce the dns that you chosed, and you are the only one who should chose your dns, bot your isp or anyone else
-doh bypass my pihole? set your doh to pihole
-doh bypass enterprise blocklist? if you rely on mitm attack over dns to implement it you are doing it wrong.
-doh bypass my hosts file? Get a firewall, pointing domain to 127.0.0.1 is not the proper way to block internet communication, a firewall is.
That app might use hardcoded ip and bypass your hosts file and pihole EVEN WITHOUT DOH so if your problem is blocking get a firewall! And stop complaining about doh

Tl;dr: pointing domain to localhost is not good to blocking comm. Direct ip connection exist get a firewall, doh is not the problem, you are the problem, you are doing it wrong

Jesse Thompson • February 25, 2020 2:43 PM

Look, I’ve got the solution to every problem mentioned here.

Neither DoH nor DoT protect user from ISP seeing HTTPS host fields? Over-sold promises to dissidents could put them in hot water with hostile governments?

Easy, I’ll just start a virtual-desktop service and then absolutely all of your online activity can be encrypted! Bruce ought to love that, right? Perfect security. 😀

You’re worried about communicating or collaborating with person X but you need end-to-end encryption with them? Easy, when your virtual desktop makes network connections to their virtual desktop, we bridge your connection in the middle and no packet on the wire will ever not be encrypted. And encrypted === security, right?

Worried about criminals going dark? That’s no problem, our virtual desktop service collaborates with Law Enforcement to support legal investigations into whatever it is they’re after, all to keep you safe.

Concerned about moving the processing to the cloud reducing available features? Never fear, our software will maintain 24/7 control over your local hardware resources such as microphone, camera, smartcard reader, USB ports, etc so that all of your favorite services will always be right at your fingertips via our virtual desktop interface.

Uncertain about “moving trust elsewhere”? Well never fear, our solution was explicitly designed to move all trust in the system directly to me! and if you can’t trust me personally, then who can you trust with 100% of your digital activity and sensing devices, amirite? 😀

Think of the CHILDREN! • February 25, 2020 2:59 PM

So let me get this straight… if you’re pro-privacy, you’re an “internet villain” because we can’t spy on every single thing every single person worldwide does on the internet, to find child pornography (“think of the children” argument) or terrorists (oh, the old “you must be terrified” argument)…

By this argument, manufacturers of clothing should also be branded “villains” because they allow people to conceal weapons (i.e. think of the children, and the terrorists). Everyone should be forced to walk around naked to make sure they’re not going to blow everyone’s heads off….

Secure BY DEFAULT • February 25, 2020 3:15 PM

If you’re used to relying on breaking security/privacy to implement some sort of needed feature… and you find that this new world we’re headed towards where everything is secure/private by default is breaking your feature, then you’re really living in the past. The people have spoken. They want control over their own devices. They want security by default. They don’t want to be spied upon constantly, they wish to have privacy. Of course, on the flip side, they’ve also spoken: as long as it doesn’t cost more. Most people will not pay one iota extra for security or privacy… but all things being equal (especially cost, usability, etc), they’ll prefer security and privacy. If you can’t handle this brave new world, maybe you need to consider changing your world view.

www • February 25, 2020 3:25 PM

@Secure BY DEFAULT: We want the same things, but we disagree on how to get it.

This is less a case of “the people have spoken” and more “Mozilla has decided.” As one of the few options not actively hostile against user privacy, Mozilla’s decisions are a big deal.

DoH “frees” people from having their devices controlled by one set of adversaries by handing that control over to another.

You’re right about cost, of course. But DoH isn’t a cost issue, it’s a technical direction issue. We can achieve the same/greater security and privacy by driving OS-level DoT/DNSCrypt adoption rather than DoH.

Homer Simpson • February 25, 2020 3:50 PM

I did not know where to put this, the latest
‘The Simpsons’ will humorously explain, completely
how bitcoin and blockchain work

D’oh!

Tatütata • February 25, 2020 4:42 PM

Can someone tell me how local domains are supposed to be resolved using DoH? If I need to access a router, a printer, an access point, or any another machine in the 192.168.xxx.xxx or 10… ranges , how will the DNS exchange look like?

Now I have domain resolution by the router, and configuring local addresses is something of a PITA with the DNSMasq implementation.

Back to IE6 • February 25, 2020 8:49 PM

Sorry, Bruce, I really agree with almost everything you say but must take a stand against this. Peace.

Quoted for truth.

I understand if @Bruce is looking at this from a larger, societal / public-use perspective -and sure, I get that from a Herd Immunity angle or as a global policy, this might be on balance beneficial to society – but a lot of us readers are enterprise admins, particularly in the USA, and DoH is absolutely terrible for us trying to protect our networks and dumb users from themselves / securing our employers or customers organizations via DNS filtering.

I prefer NOT to break TLS/HTTPS with certificate injection / inspection wherever possible. So I’d rather do filtering at the DNS level combined with a high quality AV/EDR (and email spam filtering, etc). This DoH change breaks half of my regular network security stack.

I run my own DNS servers that have TLS protection between my on-prem DNS servers and their upstream DNS providers. I do that for two reasons: to protect my public facing DNS queries from snooping, and/while to be able to filter my client-to-server DNS queries. Anything that by default circumvents my enterprise-provided DNS settings and protections is bad… No two ways about that.

Firefox just got uninstalled from 100k+ endpoints. Sorry users… but you just cant be trusted to not watch Japanese scat porn on the conference room projector while not downloading Russian malware torrents on company time.

/shrug

Rachel • February 25, 2020 9:08 PM

It’s worth remembering, Mozilla has countless holes in their ‘we respect privacy’ facade. about:config is riddled with corporation telemetry. They phone home and everyone else every which way but loose

as Clive Robinson noted recently Firefox code is now complex and bloated beyond the point of no return. The capacity of Firefox to browse websites should be considered a side effect

Dave • February 25, 2020 10:05 PM

D’oh! is a really dumb idea that’s being forced down our throats by a couple of geeks at Mozilla and Google who have run out of other ideas on what to tweak next. Firstly, it does nothing because the very next network operation after a DNS request is to go to the site that you did the DNS query for. Secondly, I decide where my DNS goes, and that’s to my local ISP, who couldn’t care less where I go, not to Google or similar who really, really want to know where my DNS queries go. In addition since I’m running a PiHole I want my DNS queries to be run over DNS, not over D’oh!, so that I can filter out all the bad sites.

So in summary it has a whole shopping list of really serious things wrong with it, while providing no benefit to me whatsoever. It’s security geeks saying y’all watch this, nothing more.

name.withheld.for.obvious.reasons • February 26, 2020 12:03 AM

@ Tatütata

Can someone tell me how local domains are supposed to be resolved using DoH?>

Currently I understand that the resolver within Mozilla’s Firefox is the caller to the hosted service. Other applications would have to hook the API to utilize, though Microsoft is planning a DOH which should really be DNS over TLS (DOT). The plan by Microsoft would have the DNS resolver for the OS would be DOH compatible.

From what I understand there is a fallback query logic that goes from the highest level access down to lower levels. Not sure how the localhost or local resolver in a resolv.conf stanza might behave at this point. I would assume a similar behavior where the local host file will be the first interrogation the local DNS database, and then any externally enumerated servers.

Steve • February 26, 2020 12:15 AM

I read nearly all the comments and they missed this: there are ransomware using DoH. So, unless you add every DoH provider to your HOSTS file (blocking them,) you have a potential security issue at hand. Since DoH makes all IOCs IPs irrelevant; you cannot see them anymore.

Drone • February 26, 2020 1:49 AM

Mozilla Speaks – Addresses concerns about DoH in new Blog post:

“The Facts: Mozilla’s DNS over HTTPs (DoH), Mozilla February 25, 2020”

https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozillas-dns-over-https-doh/

My first take on DoH in Firefox (FF)…

  • Look, DoH is better than nothing, which is what we have today and except for DoH the foreseeable future. Mozilla has put two years into live testing DoH in FF and it’s ready now.

  • Schemes better than DoH are taking forever to emerge and all of them seem to be more difficult to deploy.

  • If something better than DoH comes along, no problem. You just gradually dual feed and transfer over to it. No big deal. In the meantime we still have DoH, which in many/most cases is better than nothing.

  • If you don’t like/want DoH in FF, just turn it off, it’s reportedly as simple as flipping a switch. Voila, FF is back to the way it was before.

  • If deploying DoH pisses off Governments, Standards Bodies, Regulatory Agencies, ISP’s, Software/Hardware Corporations etcetera who all think they have a better idea – then GOOD. Maybe they’ll get off their collective arses and do something for a change. Nothing else is getting done today and DNS is still hanging out there in the naked.

  • Enterprises easily have full control over the computers they own and that their employees use at work. If a company doesn’t want DoH no problem, just flip the switch in FF. The Sysadmin locks down the User account, sets up Firefox how he/she wants, and sets the Firefox Master Password. Poof, DoH is gone. Or the Sysadmin can setup DoH in FF different from the default and still use it.

  • There are only two DoH capable DNS resolver systms for Firefox, Cloudflare and NextDNS. Yeah, I don’t like this either, but you gotta start somewhere. The number of servers will grow as DoH for FF does (if it does), and reputations will be earned over time. If you don’t feel safe as an early DoH adopter, just turn it off for now.

  • Mozilla seems to have put some thought into accommodating stuff like parental controls etc. Time will tell. For example Mozilla is not deploying DoH in the UK yet until concerns in that market are addressed.

Dave • February 26, 2020 1:54 AM

@www: It baffles me how security experts can support the move to DoH.

From an informal survey, the majority of security people I’ve talked to recognise it for what it is, a really dumb idea. As Paul Vixie (I think) put it, the only people who think D’oh is a good idea are people who don’t understand DNS.

Phaete • February 26, 2020 2:01 AM

So it is on by default (non UK), and now they have chosen now where to send your surfing data if you just update your browser.
Money grabbing in the disguise of security delivered by bloatware.

Drone • February 26, 2020 2:35 AM

Whoa there parner, Re: my previous comment on the #DoH Twitter account (I always forget to cut the URL tracker trails). Use this instead:

https://twitter.com/hashtag/DoH

Soooo… Is this the Twitter account for the Department of Health (DoH) somewhere? Never-mind, there is still a bunch of recent DNS-over-HTTPS posts there. Yeah, Twitter – what a mess (laughing while typing this).

Not_A_Robot • February 26, 2020 2:42 AM

DoH can mess up some things with DNS, that’s for sure. That’s one of the reasons why I have 4 browsers on my PC at work. Standard Chrome, DoH enabled Firefox in anonymous mode, Epic browser for easy access to proxy servers and Tor Browser just for fun.

nsa disinformation • February 26, 2020 4:35 AM

seems that is full of anti-encryption comments, with no sense arguments like “omg my corporate dns filtering doesn’t work anymore”.
well if you rely on dns filtering to prevent people accessing websites you are doing it wrong:
1-people could change their dns and stop using the corporate one
2-people can use direct ip and don’t use dns at all
3-people can use google translate
4-people can use so many tunneling ways that even china firewall can’t keep up

so stop blaming doh for your incompetence, if you want to filter websites you block them by ip with firewall, not by dns.

another no sense thing is “mozilla decide what is my dns” nope, you decide!
want to use doh? chose between providers that support it: cloudflare, google, …
don’t want to use it? turn it off.

i’m using system wide doh with dnscryptproxy.

and not only! i’m going to turn it on NETWORK WIDE from the router as soon as the fritzbox update is published!!!

Spellucci • February 26, 2020 6:23 AM

Amusingly, it appears TechCrunch’s security certificate has expired, and my browsers block me from seeing the article.

Who? • February 26, 2020 1:42 PM

@ nsa disinformation

I agree with your comments. Filter at the firewall level not the naming service level (alternatively you can write down on a paper sheet the IP addresses of those “filtered” servers you want access to before going to work).

In any case, if a corporation is against DNS-over-HTTPS they can set up their own recursive name servers and block any access to port 53 on servers not controlled by the IT staff.

Who? • February 26, 2020 1:52 PM

I would like to run a sort of “poll” in this forum, as the best security experts are here and will provide accurate feedback. Ok, not really a poll, I just want your knowledgeable opinion.

What it your choice for a naming service? I am talking about standard name resolution, the one done at the operating system level.

  1. OpenDNS? (208.67.222.222, 208.67.220.220, and 208.67.222.220)
  2. Cloudflare? (1.1.1.1, and 1.0.0.1)
  3. Running your own local recursive name server connected directly to the root servers?
  4. Other choice?

I am not sure OpenDNS, now owned by Cisco, and Cloudflare are so privacy-aware as they say. Even Google says they care about our privacy (…or lack of).

John L • February 26, 2020 2:19 PM

Firefox’s version of DoH sends your DNS query stream to Cloudflare. Is there any reason to trust them more than the people who run your network with whom you have a business relationship? Not that I can see.

Clive Robinson • February 26, 2020 2:22 PM

@ Who?

Options 1&2 have proved themselves untrustworthy, either to corporate or Gov IC intetests (which are about the same these days)…

Whilst there are some strange things you could do for option 4, The hassle of option 3 might be less because it’s a more troden path…

Michael • February 26, 2020 2:50 PM

Everybody is so quick to blame Mozilla, but realistically, the whole industry is to blame. We’ve been dragging our feet for DECADES on implementing secure DNS. It’s one of the last major gaping holes on the internet and we’re long overdue for securing DNS. Mozilla’s strategy is aggressive because it needs to be; if they kept it off by default, the industry could continue to drag their feet on implementing and deploying secure DNS.

Google has employed similar strategies with their search engine and Chrome web browser and to great effect. If you don’t pressure companies into upgrading security, they probably never will. If not for the efforts of Google, Mozilla, EFF, and others, the majority of websites on the internet would likely still be unsecured.

So rather than complaining that Firefox is ruining your enterprise structure, embrace it, appreciate that this is going to greatly improve security and privacy for everybody, and learn how to adapt.

Who? • February 26, 2020 3:47 PM

@ Clive Robinson.

Clear enough, thanks!

I agree with you. Both Cisco and Cloudflare are north-american companies that may have been targeted with NSLs, not to say the entire networking industry has bugs (I would say full backdoors in most cases) ranging from accounts and passwords hardcoded in production operating system releases to really odd bugs that can be exploited by means of tools like EXTRABACON and EPICBANANA making them look untrustworthy.

As you I think option 3 is a good compromise between public naming services and in-house solutions—I have been doing it for years. Obviously much better than a fully populated multi-gigabyte /etc/hosts file (option 4). Not really private, but we are talking about name resolution at the operating system level and logs are in our hands.

Uhh, dude ... • February 26, 2020 4:03 PM

… even some in the security community are split, amid warnings that it could make incident response and malware detection more difficult.

Dude, the ladies in the back office are splitting their legs and pressing rape charges over your web browsing history.

The “incident response” which they require is generally referred to “in the biz” as SWATting.

Malware detection? Anything capable of connecting to SSH, database or other “management” ports is malware. Period. Overly solicitous parents and tech-illiterate MBAs with undergrad college majors in psychology. Extremely conservative religious patriots (Mormons) at the NSA data center in Utah (Bumblehive etc.) looking over your shoulder as you surf the Internet… Oh, yeah, don’t tell anyone but they have banks in S.L.C., real banks. Why do you keep losing your identity at those online banking sites? Maybe you need psychiatric help https://www.identitytheft.gov/ to make a recovery plan — the government has diagnosed you with dissociative identity disorder and deemed you to be suicidal and ineligible to possess firearms for the rest of your life because you looked up poisonous death cap mushrooms online. Or maybe you’re a serial killer who shouldn’t have a gun because of what you were looking up on the web.

Dr. Oink • February 26, 2020 4:52 PM

If the desire is to keep ISP (i.e. gov’t or what-now) from tracking your web surfing then some kind of VPN service might be a better approach

Dave • February 26, 2020 5:28 PM

@John L: Firefox’s version of DoH sends your DNS query stream to Cloudflare. Is there any reason to trust them more than the people who run your network with whom you have a business relationship? Not that I can see.

I trust Cloudflare, under the jurisdiction of the Committee for State Security… sorry, Department of Homeland Security, not to mention fairly probable penetration by the NSA, MSS, Unit 8200, FSB, and everyone else, infinitely less than I trust my local ISP, who is a very long way from US jurisdiction, and in a country with strong privacy protection laws. In fact I trust every D’oH provider I know of vastly less than my local ISP.

Uhh, dude ... • February 26, 2020 9:46 PM

@Dave

I trust my local ISP,

Good fellows, aren’t they? They probably eat lunch with you at the telco employees union hall. Or else there’s a pub down the street serves German food and beer, and they’re always having a “hackathon” or something like that.

It was a quintillion-dollar scam, but that’s only a billion dollars to Mike Bloomberg, because those union benefits never really did translate to real cash take-home pay.

https://www.bloomberg.com/news/features/2019-10-08/quintillion-ceo-s-promise-to-wire-the-arctic-was-1-billion-scam

myliit • February 26, 2020 11:33 PM

@Dave

Why would you trust your local ISP? I think they are, in general, trying to play catch up in the Surveillance Capitalism game.

How about DNScrypt?

NotAName • February 27, 2020 4:18 PM

I think that DOH does solve an important problem, but I wish that the solution was not just “ask authority ‘Cloudflare’.”

The original idea of having multiple, reasonably independent root name servers is an excellent one, and DOH would have benefited from a similar structure.

Vatos • February 28, 2020 12:48 PM

The wikipedia page implies to me that the data that is encrypted is also available in a non-encrypted portion of a request.

How is that any kind of step forward?

It seems to me that if you want to say this is a good idea, it might be nice to list the benefits of the change.

Randy • February 28, 2020 2:49 PM

I’m baffled that Bruce says he loves it, but just about everyone else says that it’s either ineffective or a bad idea.

What gives?

Clive Robinson • February 28, 2020 9:17 PM

@ Rabdy,

What gives?

Two things,

1, Threat model.
2, Implementation.

All encrypting DNS requests does at the base level is “hide” the data from “third parties in transit”. It does not hide it from the DNS server or it’s operator.

So the threat model has a Shannon channel for communications and three parties,

1, Channel originator (client).
2, Channel terminator (server).
3, Channel observer (evesdroper).

In theory DNS over HTTPS does not hide the “fact” of the request transmission, “when” or “length” of the request from a “third party” evesdropper only the request “contents”. So the typical leaks meta-data hides data that has several known issues.

The problem is who is the bigger threat to the “first party” client… The “second party” server, or “third party” evesdropper?

In practice the first “upstream” “third party” knows most about you, that is your Internet Service Provider (ISP) because,

1, You pay them non anonymously.
2, They see all your traffic.

Untill recently this was not seen as a problem. However large US ISP’s appart from buying legislation to drive out small ISPs or ban other ISP suppliers, have started “double tapping” by not only charging over the odds service rates to customers for restricted service, but then also selling the customers details to who ever will give them money, no matter of how much “ill repute” the purchaser might be (they just charge more).

Thus DNS over HTTPS would kill off some but by no means all of this “ISP Douple tap”. Which some people see as good, I don’t happen to because it’s “A sticking plaster on a broken bone” problem. That is, it is fixing one of the symptoms of the problem not the actual problem it’s self.

This is because,

1, It does not stop third party observation of traffic.
2, It does not fix the second party issue.

That is whilst DNS over HTTPS might hide the request contents it does not hide the request or the time it happened at, nore does it hide the traffic to the site the DNS request was for. So with a little traffic analysis a state analysis of the client can be easily reconstructed. Some might argue that the use of a Virtual Private Network (VPN) would hide the “site traffic” to which I would respond no, it just shifts the problem of an evesdropping third party upstream, it does not solve it.

But this still leves the second party problem, and here is where the big issue arises.

Whilst most ISP’s have their own DNS servers which is seen rightly as a problem, the ISP especially a small one does not have enough traffic to become a fully fledged “data aggregator” which is why it was not seen as much of an issue untill AT&T started double tapping. However Google, Cloudflare and similar are not just big enough to be data aggregators, some are the most pernicious at being so and are very definitely “evil”.

Which is where we come on to the second issue of “implementation”. When you look around who provides DNS over HTTPS “servers” there are very very few and guess what they are Google, Cloudflare and others of the “evil” “data aggregator” species.

Thus if you use DNS over HTTPS you know fairly well that you are handing over yet more “private” information to the “evil” “data aggregators” that they did not get in the past…

From this point alone “DNS over HTTPS” is a very very bad idea. Though it’s defenders will argue that “with time others will set up servers”. Personally I don’t think they will, becaus whilst there were once sound technical reasons why an ISP had to run a DNS server as well as other servers for DHCP and NTP Email etc, those reasons in the main don’t exist any more and especially not for DNS over HTTPS.

But it gets worse… the proper place for domain name to IP address translation is in you Operating System (OS) where it can be shared by all applications, and propper policies can be set etc, not in any application it’s self especially one that tries very hard to make it near impossible for the average user to set up correctly at the best of times.

But due to who gives money to the application software developers you start quickly to realize that DNS over HTTPS is a “con game” by certain of the “evil” “data aggregators”.

Thus there is one thing you can almost definitely guarenty, getting this application to stop using DNS over HTTPS will become a task that even Hercules would find taxing, secondly on every update the flags and other changes you make to stop it will not just get reset they will be renamed or changed, to stop script developers and the like.

It’s also fairly likely that the DNS over HTTPS will get changed frequently in little annoying ways. Not a problem for “evil” “data aggregators” as they will be driving the changes, and not a problem for the application developers because they will effectively in on the con one way or another. But other potential DNS over HTTPS service suppliers, they will effectively be frozen out of the changes untill the last moment making their task of staying current and not having things break very difficult.

But there is one further asspect to consider, that is the FCC and their current incumbrant who is “on loan” from the major telcos. He knows he’s going to be out on his ear at some point, thus he’s subject to all the “nest feathering” activities that political appointies get upto. He will no doubt arrange for it that the likes of DNS over HTTPS can be considered “non essential” thus something an ISP either does not have to alow or can downgrade to the point it’s effectively usless. Why because that will not stop the “evil” “data aggregators” but it will force them to negotiate with the big Telco ISPs to give DNS over HTTPS to their servers usable bandwidth etc. Thus it will force out all other DNS of HTTPS service providers.

But this nasty little con that DNS over HTTPS is, has a secondary purpose. It stops any solution to the second party problem.

It is entirely possible to come up with a replacment for DNS where any request from a client can be “annonymous” thus killing the second party theft of private data dead in it’s tracks.

We realy should be pushing for such a protocol not DNS over HTTPS. The “evil” “data aggregators” by pushing the application developer to put DNS over HTTPS in the application where it most certainly does not belong, preempts and thus prevents a better protocol that makes client requests to the second party server anonymous…

But consider this, because the HTTPS protocol is in effect open to all traffic types, how do you know that what you think is just a DNS request is not some kind of telemetry or password collecting system? Wr know as certain fact because they were caught at it that both Google and Facebook were collecting and storing away plaintext passwords. Such power is like a drug, and few drug users don’t have “addictive personalities” thus they will almost certainly “revert to type” to get their power fix…

So my advice is refuse to be seduced by the faux romantic patois that surrounds DNS over HTTPS, and reject it out of hand, and instead push for a proper protocol that provides protection of “privacy” against both second party servers and third party evesdroppers, because if we don’t do it now, we will never be alowed the opportunity later.

Tatütata • March 2, 2020 10:10 AM

I manually enabled DoH on Firefox (I’m not in the US) out of curiosity, and things seemed to be working OK, until I tried a certain (IMO legit) site since Saturday, where the following message being displayed in the browser client area:

Please enable cookies.

Error 1001 Ray ID: xxxxxxxxxxx • 2020-xx-xx xx:xx:xx UTC
DNS resolution error
What happened?

You’ve requested a page on a website (xxxxxx.xxx) that is on the Cloudflare network. Cloudflare is currently unable to resolve your requested domain (xxxxxx.xxx). There are two potential causes of this:

Most likely: if the owner just signed up for Cloudflare it can take a few minutes for the website’s information to be distributed to our global network.

Less likely: something is wrong with this site’s configuration. Usually this happens when accounts have been signed up with a partner organization (e.g., a hosting provider) and the provider’s DNS fails.

Cloudflare Ray ID: xxxxxxxxxxx • Your IP: xxx.xxx.xxx.xxx • Performance & security by Cloudflare

The site in question works and in other browsers and also when I disable DoH in Firefox.

The message clearly states that the issue is DNS-related, i.e., DoH. Why should I need cookies for a DNS request? Or is it only demanded for the error page? And as far as I can tell, the site in question isn’t been served by Cloudflare, despite what the message says.

Is there a potential for censorship when most DNS requests will eventually be mediated through a handful of global CDN operators? And what if Cloudflare or some other CDN is served with a National Security Letter forcing them to hand over all their traffic records?

Tatütata • March 2, 2020 12:58 PM

I wonder, if one somehow simply relied on IP numbers directly for accessing a website, would that in theory negate any and all use of a DNS server?

A big hosts file might have still been somewhat feasible 35 years ago, but totally unrealistic today.

Originally, a web server at a given IP address served only one domain at a time. Later, in view of the necessity of sharing resources and addressing IPV4 address exhaustion, a server could serve any number of domains. DNS returns you a common address for a bunch of servers, but in the initial HTTP 1.1 handshake the client specifies which particular one it desires. Furthermore, HTTPS, which guarantees that the site you’re talking to is the one you want, wouldn’t work anymore, as it is based on the domain name and not the resolved IP address.

And more than one result can be returned by DNS: alternate addresses for traffic shaping, IPV6 addresses, MX records, etc.

cryptotime • June 8, 2021 8:59 AM

There should be a class action lawsuit on Mozilla for tuning this on by default.

Lawsuit Points:

  1. Parental controls via custom firewall dns all gone using cloudflare naked wide open dns exposing children to porn sites because users did not know how to disable this default built in feature to firefox.
  2. Advertisers probably paid Mozilla to “enable” this by default as many ad/tracking sites was being blocked by custom dns firewalls making them a ton less money, but protecting networks from malware ransomware etc that use these ad sites to spread.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.