Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims(blog.technitium.com) |
Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims(blog.technitium.com) |
1. Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass.
2. While this can be true, it’s not actually anything to do with the way DoH works. You could just as easily choose to only upgrade to DoH when the DNS provider of your choosing happens to support it.
3. Home internet is not new or uncommon. 76% of the US has internet access according to a cursory Google search. A vast, vast majority of these users are casual users. The control plane is not under their control necessarily. The control plane is not something that can just absolutely be trusted.
With much respect, I simply must disagree. The notion that DoH is dangerous feels like it comes from a dated view of internet security, and it only reflects the mode of rollout where application software indiscriminately uses a DoH server in place of the user’s default DNS server.
Further, this article has a lot of interesting claims. It claims that many websites are still not running over TLS even though it’s free. Of course, this is undoubtedly true and reflected in statistics. However, is it true in a realistic sense? How many non-HTTPS pages do you browse?
Thanks to Cloudflare and other actors, I suspect ESNI will have no trouble gaining meaningful marketshare. Not full proliferation. We don’t need full proliferation for it to be useful, though.
1. In most situations, the end-users are the ones that matter; the cart shouldn't drag the horse.
2. In situations where that doesn't hold, serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways; why should anybody give anything up to make things easier for enterprises who are just a bit concerned about security, but not enough to take responsibility for endpoint security?
I agree, if you are considering the approach of just using an arbitrary DoH server. But I think it would be nice if people would at least acknowledge that this is not a fault of DoH. One could envision a future where local DNS servers could support DoH. I don't know how far away from reality this is, though.
If this is somehow a fault of DoH, I apologize for my misunderstanding. I admittedly haven't read the full standard.
>serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways
Thank you, this is precisely what I was thinking.
That's assuming the clients and the network are adversarial to each other. Consider that the local DNS resolver may be blocking domains associated with malware or ads, which the client wants for it to do, and then changing the default DNS from the one configured via DHCP results in clients getting malware and ads they didn't want.
> While this can be true, it’s not actually anything to do with the way DoH works. You could just as easily choose to only upgrade to DoH when the DNS provider of your choosing happens to support it.
The major criticism of DoH is Firefox enabling it by default and overriding the existing system DNS configuration, requiring manual reconfiguration of arbitrarily many client devices to change it back to the way it was. There can obviously be no legitimate objection to it if it is disabled by default and only used when explicitly enabled by the user.
> Home internet is not new or uncommon. 76% of the US has internet access according to a cursory Google search. A vast, vast majority of these users are casual users. The control plane is not under their control necessarily. The control plane is not something that can just absolutely be trusted.
This is a great argument for making DoH/DoT/DNSCurve/etc. the default configuration for the builtin resolver in home internet routers. Which thereby solves the problem without introducing a new one where if you want to change the default it requires reconfiguring arbitrarily many separate applications on every individual client device, because in that case you can still configure the DNS for the local network in one location.
+1 Firefox should also consider that such network settings are only accessible to root or administrators such that organizations can maintain network policies for the devices they own in their network.
In the other cases, where DNS is being used as a legitimate policy vector, the entity enforcing that policy should also have endpoint control, which they can use either to re-establish network policy (by disabling DoH) or to enforce policy more reliably at the endpoint layer.
Same argument can be done for firewall that filters traffic using IP addresses. In the same words, it can be said that, if your firewall security policy can be defeated by using VPN, its evidently not very hard to bypass.
Just like firewall is useful for security, so is DNS based policies.
Cloudflare is doing good job but, the concern is centralization. Its not going to be good to have most internet resources being resolved via Cloudflare DoH, then accessed via Cloudflare CDN.
ESNI will take a lot of time to gain meaningful market share. There are people still arguing that their website does not need to use HTTPS since they are just a static website or do not have login/user data. Such people completely fail to understand that HTTPS is not to protect them but to their end users from MiTM script injection attacks.
It is. They can even install a VPN everywhere they want, that's how much control they have. DoH wants to take it away.
> I suspect ESNI will have no trouble gaining meaningful marketshare.
You have not been paying attention. Those same organizations removed the exact ability esni proposes once governments applied a bit of pressure on them (I'm talking about collateral freedom domain fronting thing).
The network control plane is not on the end user’s computer. For a home network, this is probably their ISPs modem, followed their ISPs actual edge. You could opt to set up your own DNS server or use an alternate DNS server, which is bypassing the control plane, assuming your ISP doesn’t force you to use their restrictive equipment.
The difference between DoH and regular DNS here is that even if you choose another resolver, unencrypted DNS can still be intercepted, logged, and modified by the control plane; many providers have been doing this to monetize NX DOMAIN responses even when the user is using another DNS resolver. I first realized this when attempting to get rid of annoying NX DOMAIN search SPAM pages on my phone years ago... That is precisely why this issue is coming up now and not earlier when cleartext alternate DNS resolvers gained some popularity.
> DoH wants to take it away.
What does DoH take away? You can still configure your resolver today.
> You have not been paying attention. Those same organizations removed the exact ability esni proposes once governments applied a bit of pressure on them (I'm talking about collateral freedom domain fronting thing).
What have providers removed from ESNI?
I'm still waiting to see a genuinely technical disadvantage of DoH. All that I've read so far are social and implementation related issues that can be ironed out over time.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
My home network has a DNS server that already talks to the outside DNS servers with TLS, so having browsers reach out to cloudflare would prevent cross-device caching and only protect against snooping on my LAN or wifi, which I don't find to be very necessary. So I just made this domain return NXDOMAIN.
This is a totally wrong usage of DNS and I wish we would focus more effort into making IP-based blocking easy and accessible rather than wasting time trying to make DNS fit this niche. DNS is not the right tool for this job and maintaining this functionality is not a valid reason to block progress on more private technologies like DoH. And it's totally possible to run a PiHole-style system using DoH anyway.
however, your statement is wrong.
i won’t go further into detail because my comments on this subject universally attract all the downvotes so there’s no point. but in general the problem is you need to qualify “safest”. safest for what and for whom, and in what scenarios? you’ve left too much unsaid, so what you say is not generally true.
At least a comment that attracts downvotes may be useful to someone.
In theirs, they read the DNS servers from the OS (like the original), and then if it's part of a list of known DoH providers, they try to connect over DoH before falling back to regular DNS queries.
Virtually all the opposition to DoH is rooted in two complaints:
1. It centralizes DNS at Cloudflare (obviously, you can point DoH elsewhere).
2. It's hard for network operators to block it (which is the point).
That only fixes the "Cloudflare" problem. It still centralize all DNS traffic onto a single service. I cannot configure Firefox to send packets only to the (hypothetically DoH capable) delegated nameserver(s) for each domain.
When you run your own recursive resolver (which is easy), only the lookup of the NS delegations needs to use a centralized service. This is relatively infrequent (NS records rarely use a very short TTL), so regular (TTL-respecting) caching prevents the centralized service from learning your pattern-of-life.
The DNS traffic for the A/AAAA records[1] is very different. Short TTLs are commonly used to force a DNS check every few minutes. In practice, this means a user's aggregate DNS traffic contains a very good pattern-of-life about the services they use and when they use them. When you run your own recursive resolver, nobody can learn the entire pattern-of-life; the traffic is distributed to different servers for each domain delegation.
If I could configure DoH at the system level, as I do normal DNS, I'd be perfectly happy. As it stands, DoH could trivially be co-opted by browser vendors to ignore system DNS settings, and even if it isn't, it still makes DNS configuration a worse experience.
Currently, the only way to configure it is manual and application-specific; there's no way to configure it for all apps and automatically, like DHCP for the normal, 53/udp DNS. Nobody is going to manually reconfigure their DNS every time they switch network (e.g. home -> office -> customer).
edit P.S: I'd never trust ISP's DNS servers, because it's the easiest way to track what customers does.
Wouldn't be a proxy checking the SNI of connections you open better?
Lack of privacy issue aside, there are a bunch of technical disadvantages compared to alternatives. Like using encryption to a local resolver or to a resolver over trusted or encrypted network is unnecessary overhead and complexity, including operational complexity that you really want to avoid. And if there is a case to use encrypted communications with a recursive resolver (i.e. non local), it could be done by simply tunneling DNS protocol over any of existing crypto protocols, no need for yet another complex protocol tunneled over https that still has to be converted to a native DNS protocol down the line.
As for not using TLS/http to wrap the dns queries for secure transport across the net, what “existing crypto protocol” do you suggest they should have implemented instead?
Users access services by DNS name, so if you want to control access it has to be at that level. Whether DNS can be effectively blocked while maintaining privacy is another issue, but I can't see IP-based blocking helping here.
- proxying ad requests through the server of the website you're visiting;
- accessing ads by IP address directly; or
- using randomly generated domain names.
With a browser-based ad blocker, those measures would still be an obstacle, but at least you'd have a chance - you could switch to more heuristic ways of detecting ads based on, say, the scripts involved, or the content of the media being downloaded, or its size and placement on the page. None of that information is available to network-based blockers, at least not when HTTPS is in use.
Admittedly, those things probably won't happen anytime soon, at least not for regular website ads. (Though as one example, Twitch has already started using fairly sophisticated measures to bypass ad blockers for their video ads...) But I'm an idealist, and I like to fight on favorable territory. When it comes to cat and mouse games, I don't want to be the mouse.
Instead, any blocking needs to be done on the device, whether it be MDM for any business-related blocking or via Parental Controls/Restrictions for blocking porn.
Step 1 is a mechanism for those, who do not want to fight the network policy, just want the autoconfiguration.
This is not bypassing the control plane, this is the control plane. Each device is essentially its own network that connects to other networks. This is how operating systems work today.
> You can still configure your resolver today.
Yes, because of people who pushed back Mozilla.
They should look up a canary domain that doesn't resolve from the roots, but local sites can configure to provide the address of a DoH resolver. Then you don't need to have a list of known DoH providers-- any site can install a DoH resolver and then add the canary domain to allow clients to upgrade.
It'd still be vulnerable to MITM attacks on initial connect, but at least the window for them is closed after the first resolution with this approach (better than normal DNS).
Adversarial networks exist, which is why something like DoH or DNSCurve should be used in favor of unauthenticated DNS over the internet, but the real issue here is independent of which DNS protocol is used -- it's how the recursive resolver is chosen.
The canonical answer to that is to use DHCP or similar to distribute the resolver that should be used for the local network, and allow the user to manually configure a different one in any case where that one is untrustworthy. DHCP is the ordinary method of endpoint control for configuring the endpoint's DNS server.
The endpoint shouldn't have to be exposed to manual configuration or give up even more control over other unrelated settings by adding their device to something like a third party Active Directory domain just to be able to plug into a local network and have local name resolution work.
And what makes Cloudflare any more trustworthy than the average ISP? Isn't that just switching the user's resolver from the network they explicitly chose to connect to, to a centralized third party that they didn't?
That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recursive resolution locally.
It seems like you're only considering privacy at the protocol level. While that's important, it can eventually be fixed with improved protocols. I'm far more concerned about de facto standardizing on requiring a centralized service that necessarily has access to the plaintext DNS traffic. The only way to prevent logging of the user's entire internet pattern-of-life is to not give the entire pattern to a single entity.
To be clear: we should be updating all plaintext protocols with encryption/etc. Both DoT and DoH can help achieve that goal. Some sort of encrypted protocol is needed even when running a recursive resolver (such as DoT). It would also be great if popular OS had built-in support for running a local recursive resolver, OS-level support for DoH/DoT, and other advanced features.
The only reason anyone advocates DoT is because network operators can block it, forcing people to use plaintext DNS. Somehow, the meme has been created that DoT is somehow better or more privacy-respecting than DoH, but that's obviously false.
That doesn't appear to be true, according to RFC 8484. DoH cannot be used for encrypting communication to domain-delegated nameservers. Running your own DoH server just moves the problem to a different host. If I run a DoH server locally as a recursive resolver, the encryption between the browser and the DoH server is useless. The DoH server still sends the requests to domain-delegated nameservers in plaintext.
The protocol is explicitly[1] focused:
on communication between DNS clients (such as operating
system stub resolvers) and recursive resolvers.
might be manual (such as a user typing URI Templates in
a user interface for "options") or automatic (such as
URI Templates being supplied in responses from DHCP or
similar protocols).
A DoH client MUST NOT use a different URI simply because
it was discovered outside of the client's configuration
may create additional operational, tracking, and security
hazards that require limitations for safe usage.
Two primary use cases were considered during this protocol's
development. These use cases are [...] allowing web applications
to access DNS information via existing browser APIs in a safe way
consistent with Cross Origin Resource Sharing (CORS)
> There's nothing "centralized" about it
Requiring that a client "MUST NOT use a different URI" is the very definition of a "centralized" protocol. Moving to DoH from my existing local recursive resolver would be a huge loss of privacy. If there a way DoH can compartmentalize DNS requests to the domain specific nameservers, I would like to know how.
[1] https://tools.ietf.org/html/rfc8484#section-1
You don't have to use Cloud Flare for DoH, and I wouldn't.
That's assuming the DoH provider isn't monitoring queries either. Doesn't Cloudflare have a deal with APNIC to do exactly that?
> You don't have to use Cloud Flare for DoH, and I wouldn't.
That's the point -- the problem isn't that DoH exists, it's when an application changes your DNS provider to Cloudflare by default instead of using the one you have in your system configuration.
I won't use Firefox to begin with (I'll reconsider when it's mostly Rust!), and so don't care so much about how Mozilla is handling this. Personally, I wouldn't touch Cloud Flare with a 10 foot pole. But that's not what I'm commenting about; I'm talking about DoH itself, which is an unalloyed good thing, which you can tell in part by the fact that the knives are out for it.