A little bit of technology buzz is being generated around Firefox and the “default” implementation of DNS-over-HTTPS (DoH). Mozilla has decided that at the end of this month (Sept. 2019) they will start rolling out DoH as default in the browser. I’m assuming you’re familiar with DoH.

Let’s address the most obvious problems for enterprises. DNS represents a wealth of information gathering within the four walls of a business. Content control, security protections, and split DNS are just a few things to mention. Breaking host level DNS resolution of browser is a threat against these protections. The security team should already be accounting for this in their SWOT as malware has already adopted this for C&C.

Mozilla has a plan for this and has set up ways Firefox will fall back to host DNS resolution, per network session (coffee shop, home, vpn), with a few specific checks.

When does it fall back? (I don’t know all the methods and I need to get back on nightly)

• A canary domain listed in content control systems. If the lookup is triggered Firefox realizes the host is within a content control DNS system. OpenDNS/Umbrella immediately comes to mind with their operation of exampleadultsite.com. Not actually an adult site.
  • The problem for users- blacklists are a mess, standards, and are they really going to get worldwide participation to have this canary domain created? You could write a whole blog about the gaps in these systems.
  • By the way – DoH will not be enabled in the UK because of this exact issue.
• Safe search redirection is triggered, in the example www.google.com resolves to forcesafesearch.google.com
• Non standard TLD detection and RFC1918 responses. This isn’t a bad attempt at triggering the fall back, but many enterprises focus on split dns which is a valid TLD. IPv6 also throws a wrench in this logic.
• Windows and macOS, detect parental controls enabled in the operating system

So what can you do inside your enterprise?

Blocking Cloudflare is not a good solution even though that may be the initial reaction. Cloudflare obviously does a lot more than DNS and keeping up with blocking a CDN is just a painful management point. Don’t do this.

Today, Firefox may not be included in your desktop system management and this will likely become a future requirement. Users are able to manually enable DoH and specify a custom provider that isn’t Cloudflare.

You can signal non-managed Firefox installations with the canary domain, which would work while machines are on-network. This canary domain “use-application-dns.net” needs to return NXDOMAIN instead of the A or AAAA IP address. Again, to reiterate this will not block a user manually enabling DoH.

Running a proxy and/or edge decryption clearly presents you with additional options to block this configuration.

So what’s the most logical step? Welcome to Firefox for Enterprise!
… Sorry, more management, but that isn’t all bad. Consider adding Firefox as an allowed package alongside an enterprise policy.

If you’re doing psexec checks to block Firefox or SWIM then you’re controlling things differently. If you want to allow Firefox then you need to give it a policy. Firefox will check for enterprise policy to disable DoH.

• Is the Firefox security.enterprise_roots.enabled preference set to true?
• Is any enterprise policy configured?

Also, if you’re allowing Firefox in the enterprise I hope you are already controlling security.enterprise_roots.enabled. Firefox runs their own root program and you should be controlling those circles-of-trust. Did we not clearly explain the circle of trust to you, Greg?

What would be my recommendation? Deploy Firefox with Windows group policy ADMX templates, macOS/Linux file distribution.

Firefox ADMX templates can be found at https://github.com/mozilla/policy-templates/releases

DNSOverHTTPS – Locked

Configure DNS over HTTPS.

Enabled determines whether DNS over HTTPS is enabled

ProviderURL is a URL to another provider.

Locked prevents the user from changing DNS over HTTPS preferences.

https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps

I hope I covered this information accurately. If I got anything blatantly wrong feel free to call me out and I’ll edit.

Thanks!

________________________________________________

The rabbit hole.
https://github.com/mozilla/policy-templates

Source link: https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https

Source #1: “If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored.”

Source #2: “When any of these checks indicates a potential issue, Firefox will disable DoH for the remainder of the network session, unless the user has enabled the “DoH always” preference as mentioned above.”

Source: Pi-hole is already on it — Within the past 24 hours of this post this canary domain was merged into development https://github.com/pi-hole/pi-hole/pull/2915

If you’re looking to fall deep down the rabbit hole of DNS-over-HTTPS issues then I have the link for you. The IETF has published an extensive look at DoH risks and issues at https://datatracker.ietf.org/doc/draft-livingood-doh-implementation-risks-issues/