The cat is out the bag, so to speak. I foresee a lot of adware, spyware, and malware leveraging DoH now to evade just about every DNS-based monitoring/blocking/provisioning solutions.
Anyway, the right layer to monitor for Internet traffic has always been the IP layer (VPNs notwithstanding).
Adware, spyware, and malware has always had the ability to avoid system DNS. At its most basic, they could hardcode lists of IPs into their malicious code. At its most complex, the same building blocks that DoH/DoT use were available to them: they could build similar tools that tunnel over HTTPS/SSH/etc, whichever protocol they felt was least conspicuous on their target system. Drop a list of hostnames into a pastebin post, tell your malware to check the list for updates, profit.
DoH in Firefox simply makes the above issue harder to ignore. Before this, an enterprise or individual sysadmin could implement DNS inspection at the border, see logs showing their users browsing naughty websites, and feel like they’d made progress. But they’d always be blind to attackers (or nefarious users) who just didn’t bother using the stock DNS offering to bootstrap their hijinks. Detecting that has always required device-level monitoring or further MITM of traffic; learning about DoH makes that more obvious to sysadmins, but it doesn’t materially change what adversaries were able to do already.
Which makes the malware more fragile, because the hosts are often compromised machines themselves, or are the targets of takedowns. If they include only one IP at a time (as they can do with DNS) then when that machine gets cleaned by the owners, they have no way to switch to another one. If they list several machines then anyone analyzing the malware has a list of multiple compromised machines to go have them all cleaned at once. Also, then you can add the IP address to a block list and they can't update it like they can with DNS.
> At its most complex, the same building blocks that DoH/DoT use were available to them: they could build similar tools that tunnel over HTTPS/SSH/etc, whichever protocol they felt was least conspicuous on their target system.
Malicious javascript in a browser doesn't have access to SSH or similar. And that's assuming their code can even reach your machine if your Pi-hole is blocking the DNS name of the server hosting it.
> DoH in Firefox simply makes the above issue harder to ignore.
It makes it harder to prevent. Someone sends the user an email link to a URL containing an unpatched browser exploit or a link to a malicious binary. If the Pi-hole blocks the domain and/or the IP address in the email, the attack is prevented. If the browser bypasses the Pi-hole, you have malicious code actually running on the user's machine, and that's a much bigger problem.
> Also, if they use an IP address then they can't be using SNI to host it on the same IP address as several other domains
Sure they can, just hardcode the "Host" header value as well
> Malicious javascript in a browser doesn't have access to SSH or similar.
They can access HTTP though, which is more than enough.
Over HTTP from what? You would need name resolution or a hard-coded IP address to make an HTTP request.
And the thing this is preventing isn't just what the malware does after you're already infected, it's the path to receiving malware to begin with.
For non-tech companies, replace with any relatively popular wiki.
The goal is “make a connection over HTTPS or other normal-looking protocol, to a destination that is both justifiability relevant for normal user traffic and allows the attacker to seed the next-step”. And it turns out there are lots of sites that fit that bill.
They're not going to leave malware payloads sitting there. Pastebins etc. get abused as malware command-and-control systems all the time, and of course some gets through, but countermeasures happen. Whereas for a DoH server it would be operating as designed.
The issue is “how do I tell my bootstrapper where to get a payload from in an inconspicuous way”. To solve that, you find a benign site with existing business purpose (like GitHub or a wiki or a pastebin), and you insert your desired IP address. So maybe you add it as new file in a repo under your cool new fake GitHub account, and the file just says “1.2.3.4”. Now you can tell your bootstrapper to make an HTTPS request for that file, which looks boring to any introspection because outbound requests to GitHub are normal, and to use the resulting IP to request the payload.
Your compromised payload host gets shut down? Spin up a new one, and update the file on GitHub with the new IP.
A simple GET request to https://github.com/adkafdjsh20/cool_repo/blob/master/dns.txt would work for DNS purposes.
Also, there are countermeasures for malware domains themselves, as you can report them to registrars.
https://support.mozilla.org/en-US/kb/configuring-networks-di...
Someone previously mentioned Pi-Hole. Pi-Hole provides the DoH canary domain in it's default configuration, therefore if you run an up to date Pi-Hole on your network you will have DoH disabled. It is recommended (and there are good instructions on the Pi-Hole website) to set up cloudflared or a similar DNS resolver which implements DoH as the backend to Pi-Hole, allowing it to use DoH when leaving your network but still act as the local network's authoritative name server.
If you choose to be a network operator, there are some additional complexities you must think about. For those (majority of) users that choose not to be network operators, DoH is nearly transparent for them and provides significantly improved security and privacy by preventing local cache poisoning, DNS injection, and DNS snooping attacks on their browsing.
Additionally, while the default in Firefox is a non-filtering endpoint currently, you can manually configure the use of a filtering DoH endpoint like those provided by CloudFlare 1.1.1.1 for Families if you wanted to do so. Nothing prevents this, and it can be configured via policies network-wide in Firefox using the enterprise policy mechanisms.
I still don't really understand this. Yes, it solves that problem, but how is it not also defeating the entire premise? If you had a DNS server from an adversarial network operator, they could just resolve the canary. So it means the browser's DoH is only secure if you can trust your network operator's DNS, at which point, what was its purpose supposed to be?
And the fear is that at some point someone is going to try to "correct" that by removing the check for the canary.
There's still some specific cases where DoH is problematic, but these are being eliminated over time as the technology matures. As an example of this, split horizon DNS in corporate environments is a good choice. Right now, the only realistic way to provide this is with Do53, so DoH must be disabled, but with Microsoft adding DoH support into the Windows 10 DNS Client, they are likely soon going to also support it on Windows DNS Server, which would enable businesses to make use of DoH internally and to simply set the endpoint by enterprise policies.
DoH is a few different things, but at it's most basic it's transport security for DNS, which is a fundamentally good idea any way you slice it. At some point in the future, plaintext DNS will effectively cease to exist and that's a /good thing/. There are several different implementations of encrypted DNS in the wild besides DoH (DoT and DNScrypt as examples), whichever you choose, any option that encrypts DNS both on your local network and across external networks improves privacy and security.
It takes a pretty long time to transition fundamental protocols like this, but a future where more things are sent across encrypted transports is a good future. Plaintext DNS is incredibly vulnerable, and it's also in an area which isn't heavily visible to most users, which is not a recipe for success.
https://wiki.mozilla.org/Security/DOH-resolver-policy
This is all publicly documented. As Mozilla rolls DoH out to other regions they will add additional TRR partners and CloudFlare won't be the only choice.
And in many cases the user is the network operator. What the browser is doing is taking away the mechanism to set local policy. Ordinarily you hand out the DNS you want your devices to use via DHCP, and they use it. If you move that from the OS to the application and the application ignores the DHCP setting by default, now you've lost the ability to set a uniform policy for all your devices and applications. It becomes an arduous manual process to change the setting in every application on every device, and then you probably miss half of them.
DNS has historically been set by network policy so that it's easy for network operators to map hostnames to their local network resources. The point of the design wasn't to enable traffic monitoring or content blocking by altering the results for hosts that aren't under your control.
For most people, their local DNS is someone like Comcast or Verizon, way less trustworthy than CloudFlare. We shouldn't reduce the privacy of the majority of people just to increase it for a small minority of people by default.
Are you referring to the whole CA system being an untrustworthy racket?
What is the burden for using HTTPS assuming you DO want to be able to inspect and block HTTPS resources at a network level? Very extensive compared to plain HTTP.
Who doesn't want that? I have a pihole (and use OpenDNS). Bypassed it all yesterday, as an experiment, to look at an anime site my eldest started using and immediately was hit with a pretty impressive and convincing phishing attempt (mimicking my ISP).
Pretty much all of us on HN seem to use some form of 'DNS' based filtering (pihole, or even just hosts file). UK ISPs offer DNS based filtering as a default (and have to filter some pages by law, and are encouraged to filter others [through threat of law]) ... but a lot of people want that, many many families, schools, businesses.
Certainly I don't want it to be easier for advertising and malware to bypass my chosen DNS-style filtering.
UK ISPs having mandatory DNS blocking is a great example of why DoH is important. The user should decide what they want, not the network operator.
Perhaps widespread use of encryption technologies means I can't do content blocking on proprietary appliances like the Chromecast for example. I think that's a necessary evil and I just won't buy such an appliance if it's that big of a problem. Only legislation can really fix that kind of problem anyway, it doesn't really matter whether Firefox implements DoH or not.
The other half of the problems are around defaulting to allowing cloudflare to inspect your traffic, instead of comcast. And the lack of integrity and encryption for the rest of the DNS infrastructure. And the expansion of the complex and difficult to secure x509 certificate regime which we should be moving away from. (Something like gossamer seems to be a big step in the right direction)
I want encrypted dns, just not a half-assed hack of an implementation that is going to be impossible to fix once deployed.
Regarding the rest of the DNS infrastructure, I agree there is more work to be done. But I see DoH/DoT/etc as a necessary step and not a "half-assed implementation" that needs to be "fixed".
> DoH in Firefox simply makes the above issue harder to ignore.
That's exactly what I mean [0]. The cat's always been there so to speak but now it is out there roaming around harder to ignore.
[0] https://news.ycombinator.com/item?id=25123487 and https://en.wikipedia.org/wiki/Script_kiddie
But tunnelling X in Y is not new at all and has a long tradition (even in regular protocol design). Is this really a shift waiting to happen in malware? As I would think, this has been available all along. Except for browser-based malware.
It does feel the world is moving away from a multi-level network to run everything over TLS/TCP (and probably eventually mainly TLS/UDP), taking away the power from me as a network and device owner, and giving it to the developers
In some parallel universe, TLS would have been part of TCP not a separate protocol and the Berkeley sockets implementation in the OS kernel would handle all encryption, certificate validation, etc, on behalf of applications. AT-TLS is a bit like visiting that parallel universe
(Strictly speaking, I'm not sure if AT-TLS actually is implemented in the OS kernel – or "nucleus" to use the z/OS terminology – it may actually be implemented somewhere else, say in the C library. I know some of it is actually implemented by a daemon called PAGENT. But, from the application programmers viewpoint, it is provided by the OS, however exactly the OS provides it.)
1) The ISP says what should be used
2) the lan either accepts that, or the operator puts their own values
3) the device either accepts that, or the operator puts their own values
Same as object inheritence. An ISP says "use this DNS server it's nearer", the network operator says "no thanks, I'll run my own with an upstream of google as I don't like your NXDOMAIN injects", the user says "actually I'll use cloudflare because I don't trust any of you"
That's all fine, and gives the power to the user.
Exceptionally if a device doesn't allow the network settings to be overwritten for some technical reason, it should simply accept what the lan sends it.
And so browsers are saying that the path should be.
1) The browser developers say what should be used.
2) The user either accepts that or puts their own values.
Ideally I think it should actually be something like
1) The OS vendor say what should be used.
2) The user either accepts that or puts their own values.
2.1) Lan operators can offer DNS servers which the user can (always) accept or (always) reject with reject being the default.
But this whole mess with browser DoH is because OS vendors are slow to move on this. Google Android does it kinda, Windows has it in beta, Linux works but it's a little DIY.
On a side note, I would love to see a system that adds out-of-band validation of an entity. e.g. My bank should have a QR code behind glass on the wall that I can scan, import a key and further validate their site at the application layer, above and beyond HTTPS and CA certs.
I guess this Mozilla Firefox change deprecates HTTPS Everywhere.
Either way, we've come a long way. For people in the Dutch security world, DigiNotar was a known joke. I knew about their terrible security (and the implications) back around 2000-2004. Although there have been more vulnerabilities too, such as Hearthbleed and POODLE.
I'm not familiar with HTST so I went looking but didn't find anything related to the web and HTTP, so I'm guessing you meant HSTS?
Of course you can just drop a rule blocking the IP address on your firewall, which will probably work for a while.
You could make the exact same kind of argument about widespread use of HTTPS for example. Do we want to allow encryption technology if it means the enemy can use it too? As a society we have agreed that encryption is a net positive even though terrorists and criminals benefit from it, but when malware uses it then that's too far?
That doesn't hold up under scrutiny. My pihole blocks ~11% of domain lookups (blocking 1000 queries per day for our household), turning it off vastly increases the unwanted content. It might seem is logical a ready hurdle, but it's a hurdle that practically works.
I don't follow the reasoning that says this is a small barrier to malware so we'll remove it.
What are we, end users, getting out of routing all our domain lookups to Cloudflare and ceding control of filtering?