25

I've heard the argument against DNS-over-HTTPS that it is supposed to be a security nightmare for network defenders because it enables encrypted DNS over port 443, compared to DNS-over-TLS which goes through port 853.

I don't understand this argument because, how is malicious traffic on DoH practically more difficult to detect and block than, say, a VPN connection over port 443 or a proxy connection via HTTPS over port 443? If you're a network defender, and you allow third-party VPN and proxy connections in your network, why would DNS-over-HTTPS make your job any more difficult than it already is, and why would DNS-over-TLS be so much better?

Martin Schröder
  • 259
  • 1
  • 2
  • 16
hilltothesouth
  • 417
  • 4
  • 9
  • 9
    You can find some explanation in the [DOH criticism section on wikipedia](https://en.wikipedia.org/wiki/DNS_over_HTTPS#Criticisms_and_implementation_considerations). It's mostly about making traffic filtering/blocking that much more difficult. This is a particular problem for ISPs (or companies) that must or want to filter/block web traffic. – Marc Aug 06 '20 at 07:15
  • 7
    I think the main problem with DoH from the perspective of a defender is not data exfiltration but reduced visibility into DNS requests. This means that more invasive (and expensive) methods like Deep Packet Inspection or SSL Interception have to be used. – Steffen Ullrich Aug 06 '20 at 07:15
  • @Marc Only the very first sentence is related to my question. I understand that encrypted DNS requests are much harder to filter in relation to blocking certain websites for, e.g., parental control. What I don't understand is how disallowing DNS-over-HTTPS will stop things like Godula from just moving over to an encrypted VPN or proxy connection instead of an encrypted DNS connection for whatever malicious things they do. How is encrypted DNS harder to monitor and analyze than encrypted HTTPS? – hilltothesouth Aug 06 '20 at 07:35
  • 1
    @SteffenUllrich That's assuming your main concern is visibility into DNS requests. But if your main concern is simply security of the network, then...? That's what my question is about. I know it makes it harder to monitor what websites/servers devices in your network are connecting to, but monitoring =/= security, and security seems unaffected to me. – hilltothesouth Aug 06 '20 at 07:51
  • 4
    @hilltothesouth: *"... but monitoring =/= security, and security seems unaffected to me. "* - There is lots of security building on the visibility of DNS, like blocking known malicious domains, restricting access to previously unvisited domains (like used in pishing) etc. Security solutions like Cisco Umbrella are build on DNS based monitoring and filtering since this is a comparable light weight and less intrusive method. – Steffen Ullrich Aug 06 '20 at 09:15
  • 1
    @hilltothesouth this question makes a lot more sense. Thanks for the edit. – schroeder Aug 06 '20 at 10:24

5 Answers5

30

Again, it's all about the threat model!

Technologies are just technologies and can be used both for good and for evil. DNS over HTTPS (DoH) intends to solve the privacy concerns there are with unencrypted DNS, whereas DNSSEC can solve the integrity concerns without a need for encryption. Together with DNS over TLS (DoT) they are all fighting the threath of a malicious network operator that spies on your DNS traffic or forges responses.

On the other hand, both monitoring the DNS traffic and forging records can also be used for good intentions like detecting and blocking malicious traffic that is depending on DNS resolution. This is where solving these technical threats can actually decrease overall security, especially on corporate networks. The threat models of an organization are naturally different from the threat models of any individuals working for the organization.

Not so easy to detect

It's true that being unable to block DoH is rather irrelevant, if VPN connections are allowed. On corporate networks VPN connections (as well as DoH) can be either forbidden by policy (weak) or blocked by TLS inspection (efficient, but sometimes illegal or requires special privacy considerations).

Compared to DoH, DoT is easy to block, as it has a dedicated port 853 (tcp&udp) per RFC 7858.

For more detailed insights on the subject I'd recommend: Drew Hjelm: A New Needle and Haystack: Detecting DNS over HTTPS Usage (SANS Institute 2019). It also has some examples of the real security issues:

2.3. Public Threats from Encrypted DNS

Organizations need to start evaluating the risk associated with the DoH protocol because attackers have already begun using DoH to look up command-and-control (C2) servers. The best-known example of DoH as a C2 mechanism came in April 2019 with the Godlua backdoor (360 Netlab, 2019). A newer variant of the Godlua backdoor runs on Linux and Windows and uses a DoH request to grab a part of its C2 information.

Another way an attacker could use DoH in an attack is to trigger a redirected webpage as part of a spam campaign. Researchers at MyOnlineSecurity (2019) found a sample where an email attachment had a Base64 encoded string that would query Google DoH for a TXT record. The TXT record would have a JavaScript redirect to a spam webpage whose address often changed.

Numerous DoH C2 proofs-of-concept are publicly available, meaning that the threat of malicious actors using DoH is likely to increase soon.

Community
  • 1
Esa Jokinen
  • 16,100
  • 5
  • 50
  • 55
  • 7
    Encrypting your data gives you privacy but the NSA hates it when they can't see your Facebook messages because that encryption is making them unable to snoop on the bad guys' (and your) data to "make everyone safer". – ChocolateOverflow Aug 06 '20 at 08:28
  • @esa-jokinen Thank you for linking the SANS Institute whitepaper. I haven't read through all of it yet, but even these researchers seem to wonder if, other than the different port which can easily be blocked, DoT is any more secure than DoH. The very next paragraph after the ones you shared states: "As of this writing, there was less risk posed by DoT as a malicious vector than DoH. First, information security news outlets have not widely reported the use of DoT-based malware using TCP port 853... Malicious activity using DoT may be a future risk, but the current threat is not high." – hilltothesouth Aug 06 '20 at 08:42
  • 16
    @JohnZhau: Or NSA loves it when HTTPS prevents other intelligence agencies from seeing the same messages they already have access to on Facebook's servers. ;) – Esa Jokinen Aug 06 '20 at 09:04
  • @hilltothesouth: Yeah. Just couldn't cite the whole paper here. – Esa Jokinen Aug 06 '20 at 09:06
  • "DoT is any more secure than DoH", HTTP brings its own set of vulnerabilities, fingerprinting (see https://tools.ietf.org/html/rfc8484#section-8.2), etc. So it is a compromise. In a purely hypothetical pure Internet without broken software or hardware around, DoT makes more sense as fewer layers. Until of course you switch to DNS messages being JSON encoded instead of "as on the wire of DNS/53", which brings you other benefits (or problems) in HTTP land that you won't have in DoT. – Patrick Mevzek Aug 07 '20 at 22:16
14

I've heard the argument against DNS-over-HTTPS that it is supposed to be a security nightmare for network defenders because it enables encrypted DNS over port 443, compared to DNS-over-TLS which goes through port 853.

These network defenders are possibly corporate environments that rely on plaintext DNS inspection to enforce policies. Assuming that devices fallback to plaintext DNS if DoH/DoT are unavailable, the network administrators could block port 853 with little risk because it is only used by DoT. On the other hand, if they simply block port 443, then all HTTPS websites will become unavailable.

Similarly, if they see an influx of DoT traffic, it could indicate an anomaly. If some similar traffic spikes occur with DoH, then it might not be possible to directly distinguish HTTPS from DoH traffic.

As for the question from the title:

Why is DNS-over-HTTPS such a big security nightmare compared to DNS-over-TLS?

This should probably be worded as "Why is DNS-over-HTTPS seen as a security nightmare compared to DNS-over-TLS?". DoH and DoT are pretty similar on a protocol level, in both cases DNS messages are encrypted. See also my Cloudflare blog post explaining DNS encryption where I describe the technical protocol details, deployment choices, and various expectations from individuals and organizations.

Historically, the operating system has been accepting whatever DNS resolver was advertised by the local network. This is typically configured by the corporate network administrator, or the ISP. They expect to have the ability to provide services such as malware blocking, parental filtering, blocking of illegal content, and in some cases query logging.

DoH and DoT are great in protecting the privacy and integrity of DNS queries in untrusted environments such as airport Wi-Fi or even snooping/interference from the local government. However since it was emerging technology, not all existing DNS resolvers have support for it.

That put early adopters such as Mozilla in a difficult position, should they abandon the idea of improving privacy, or should they select a DNS resolver who supports DoH with a strong privacy policy? They ended up with the latter, but that meant that the default DNS resolver provided by the operating system was initially ignored. This is probably the reason for the negative pushback against DoH from ISPs and governments. If DoT was deployed in a similar way, I would have expected a similar criticism.

To conclude, I don't think that DoH is such a "security nightmare" as claimed. It is just that some organizations are concerned about losing control over DNS. Previously it was centrally controlled by the operating system, but as DoH/DoT is still pretty new, there is no real standard on configuring it so many applications have their own mechanisms to do so. This is probably the "nightmare" that some admins have, the extra complexity that they have to go through to ensure that their filtering policies are applied.

Lekensteyn
  • 5,898
  • 5
  • 37
  • 62
  • 2
    "This is probably the reason for the negative pushback against DoH from ISPs and governments." The pushback is also from users that dislike any kind of software trying to pretend it knows better than the user and just ram it down its throat some decision (hardcoded DOH setting, that only slowly evolved to a selection among 2 and a selection process of other operators that just discards even DNSSEC compliance...). Other browsers made the more sensible approach of switching to DoH only if the configured nameserver is known to support it (with other problems then about discoverability) – Patrick Mevzek Aug 07 '20 at 22:09
  • "It is just that some organizations are concerned about losing control over DNS." The control is just moved from A to B, it still exists and for some it is even worse because A is decentralized (or can be, because the users chose) where B, at least in first invocation, is completely centralized, hidden from users, and difficult to change. Browsers started that trend, but other applications will do the same, which may yield to a split world view where, depending on the application, you reach completely different recursive nameservers, that could lead to completely different responses. – Patrick Mevzek Aug 07 '20 at 22:11
  • 2
    @PatrickMevzek I'll have to strongly disagree about "A is decentralized whereas B is completely centralized." If anything, now things are more decentralized than ever with applications being able to individually override the OS settings. – hilltothesouth Aug 08 '20 at 04:56
  • 3
    Pure facts though. PReviously: anyone could use any DNS and in practice often the ISP, so fully decentralized. When Firefox started to switch DOH, all requests where going to a single IP, which is what is known as centralized. The protocol itself does not change anything, any variant of DNS can be as centralized/decentralized as one wish. The problem is how DoH was introduced in browsers. As for "applications being able to individually override the OS settings. " I am not sure it is 100% benefit, it is a double edge sworded. But I guess it goes with the trend, like QUIC being in applications. – Patrick Mevzek Aug 08 '20 at 05:08
  • One item often overlooked is that DoH normalizes the idea of all DNS queries, even queries that could stay fully local (cached, local resolver, etc.), being transmitted to a remote provider in real time. To some degree this is unexplored territory -- could that provider, with all that data, de-anonomize users now or in the future? And if so, there's no way to revert back without blocking HTTPS, locking down corporate PCs, and/or MITMing *all* HTTPS traffic at the edge router. It's an erosion of network control likely to lead to a much larger erosion of privacy at some point in the future. – madscientist159 Aug 08 '20 at 18:37
  • The real risk here is the homogeneity of the internet ecosystem as a whole - companies that are arguably already too big a proportion of the Internet are using this to push their own agenda and further cement themselves, making it even harder still for new entrants to meaningfully compete in even more sectors. – Flexo Aug 08 '20 at 20:29
  • @PatrickMevzek The DoH server in Firefox has never been hardcoded, users have always been able to change it through the [`network.trr.uri` preference](https://wiki.mozilla.org/Trusted_Recursive_Resolver). As for the "more sensible" option of switching when the configured resolver appears to support it, this is the "opportunistic mode" I wrote about in [this post](https://blog.cloudflare.com/dns-encryption-explained/) and also has its drawbacks. – Lekensteyn Aug 09 '20 at 09:39
  • @madscientist159 Normal DNS queries also reach out to a remote provider, DoH does not change that. Caching of DNS records based on their TTL is available for both DoH and normal DNS. DoH is just an encrypted transport. If you have more trust in your ISP and they implement DoH, by all means configure that. But if you operate your own recursive resolver, you will actually make yourself more identifiable (less privacy). – Lekensteyn Aug 09 '20 at 09:47
  • "The DoH server in Firefox has never been hardcoded, users have always been able to change it through the network.trr.uri preference." Yeah yeah of course, nice fairy tale. Why no UI element then to change it? Just a way to force people doing something, with very little explanations. This hurts things in the long run because then people start to confuse the protocol (which has its use cases, as well as its drawbacks) from any one implementation/use of it. It also make it look like centralized for no purpose, while it is, at the protocol level, no more centralized or decentralized than variants – Patrick Mevzek Aug 09 '20 at 18:19
  • "by all means configure that." ... except in bad software that forces you otherwise or make changing it very difficult and hidden. – Patrick Mevzek Aug 09 '20 at 18:20
  • 1
    "But if you operate your own recursive resolver, you will actually make yourself more identifiable (less privacy)." Not true at all... The resolver can forward to any other one, and can also have smarter resolution by spreading the load among multiple other recursive nameservers. Just centralizing to one server is not an immediate 100% gain in privacy. It helps in a way, and creates problem in another. It is not by itself a foolproof way to regain privacy. – Patrick Mevzek Aug 09 '20 at 18:22
  • @patrick-mevzek Exactly! And that same resolver can refuse to answer queries for certain sites, both acting as a safety net against misclicks and limiting legal liability to the operator (yes, sufficiently determined users can bypass this, but at that point such actions would probably fall under unauthorized computer use laws etc. if it ever came to legal action). With DoH on corporate networks, you either accept the risk of being complicit in some illegal action by an employee, ban BYOD entirely, or forcibly MITM HTTPS. On personal networks, you're still less anonymous to the DoH provider. – madscientist159 Aug 09 '20 at 18:39
5

You're right that their argument makes no sense, but it's not supposed to. It's just supposed to derail DNS-over-HTTPS, which is the approach that is actually taking off because it's less likely to be blocked by existing middlebox junk. Assuming the queries are to well-known open public nameservers, it's equally easy to add new rules to block them regardless of which protocol is used, but the people who are fighting against DNS-over-HTTPS are fighting against the normalization of DNS queries being private; once that achieves critical mass as the default in browsers and client applications, blocking it will just break everything, making it practically unblockable.

R.. GitHub STOP HELPING ICE
  • 7,813
  • 1
  • 23
  • 34
1

A point that the other answers have only lightly touched on is that the user themselves might want to block certain DNS queries. For example, I use Pi-Hole on my home network to block DNS queries that are known to serve advertisements. Though outbound DNS queries are blocked, a device could potentially use DoH to circumvent that.

owenthewizard
  • 11
  • 1
  • 3
    DoH really has nothing to do with whether you can block ads. If the app serving them does respect your DNS preferences, you can configure a DoH server that blocks ads, and if it doesn't, then it could just as easily hardcode the IP addresses instead of using DNS at all. – Joseph Sible-Reinstate Monica Aug 08 '20 at 04:10
  • @JosephSible-ReinstateMonica, This answer is lacking detail. What I believe they're getting at is that blocking port 53 TCP/UDP on the perimeter forces one to use the internal DNS server. Since TCP443 is universally open, DoH can bypass this control. – phbits Aug 08 '20 at 16:02
0

Traditionally, blocking/allowing services has occurred at the Transport layer. DNS was confined to use port 53 on TCP/UDP. Web traffic would use TCP 80/443. So on and so forth. This makes network management easier since services are segregated via protocols and ports. DNS-over-TLS maintains this design principal since the service uses TCP port 853.

As an example, consider the common occurrence of forcing use of the internal DNS server. This can be achieved by implementing a router/firewall ACL like the following:

block drop all
pass in proto udp from 10.1.1.0/24 to $internal_dns port 53
pass in proto tcp from 10.1.1.0/24 to $internal_dns port 53
pass in proto tcp from 10.1.1.0/24 to $internal_dns port 853

Now we have all sorts of traffic traversing TCP 443 whether it be an SSL VPN, web browsing, and now DNS-over-HTTPS (DoH) just to name a few. Blocking this traffic requires more sophisticated equipment as the traffic is encrypted via HTTPS and joins other HTTPS traffic on TCP port 443. The device must be able to identify DoH via an Application Layer signature which is only available on specialized equipment. Such equipment may not be affordable for smaller organizations or they may lack the bandwidth to manage it.

You can see how DNS-over-HTTPS is a much more difficult problem then to allow or block a protocol and port combination like DNS-over-TLS. It is a shift from traditional network design to one that requires more visibility into all the different encrypted traffic traversing TCP port 443.

phbits
  • 1,002
  • 2
  • 5
  • 12