Encrypted Traffic Analysis: Encrypted DNS – Privacy, Security and the SOC (Part 1)
Where did my DNS traffic go?
DNS encryption has received a fair amount of press over the last couple of years – not as much as the ongoing apocalypse, but relatively. Much of the media content has focused on the fight between those that support DNS encryption to improve privacy and those that would like to allow DNS encryption while keeping enterprise security concerns at the forefront. For the former group there is DNS over HTTPS (DoH) and for the later there is DNS over TLS (DoT). I believe that both sides of the argument are valid – DoH will better serve those whose main focus is privacy but will have negative (but potentially not insurmountable) implications for enterprise security, and DoT will better serve the enterprise security community while undermining certain use cases for the increase in privacy; namely people who are attempting to circumvent state sponsored surveillance and censoring of their traffic. I think that the infosec community should have an interest in promoting both sides of the argument for what they are; we have a vested interest in enterprise security of course since that’s what we’re all currently doing right now. But I believe we also have a responsibility to support privacy concerns since failures of privacy are often perceived as failures of security. And as they say perception is reality!.
In this three part series of blog posts I’d like to take the opportunity to focus on what the real implications of adopting any encrypted DNS traffic protocol are for security professionals. The first part will explain the privacy implications of the three protocols (DoT, DoH and DNSCrypt), the second will explain the security implications, and the third part will explain what we can focus on as a community to mitigate any risks associated with any of these protocols being adopted on our networks.
DNS over HTTPS (DoH)
In the great Encrypted DNS debate, DoH is the option that is touted as the most privacy focused option. It uses port 443 and comes from the browser, which allows it to blend in with other HTTPS traffic, making it difficult to detect and/or block from a network perspective. Since it works in the browser, an application found on virtually every device, it is the easiest encrypted DNS protocol to use.
See, it looks like HTTPS
Firefox now enables it by default, Chrome allows you to enable it manually, the chromium based version of Edge supports it the same way Chrome does (as do a handful of lesser used browsers mentioned in the link). It looks like support is coming at the Windows OS level. This makes it difficult to block at the network or application layer, which also decreases the likelihood that your ISP or government can prevent you from using it.
One privacy implication that I don’t see discussed is that currently there are only one or two servers that browsers will allow you to use for DoH and three for the Windows implementation. While this may not be a concern for some, it means that even though your ISP or government may not be able to directly see your traffic anymore, either Google or Cloudflare will know it and potentially log it. It is entirely possible that they will then sell or otherwise use / share that information. This is an important distinction: your destination history will still not be truly private, it will just be centralized and owned by a different company… maybe that’s why the acronym spells “doh!” In order to circumvent this, you can use your own server, or another that you trust, with a DNS proxy like dnscrypt-proxy.
DNS over TLS (DoT)
This protocol is considered to be more enterprise security focused; offering an increase in privacy in some cases while ensuring that network admins don’t lose visibility. By default it uses port 853, and you need to install and configure third party software to use it (unless you’re running Android, in which case it’s much easier to configure on versions 9+ (Pie) by enabling “Private DNS Mode.”). This makes it a little less accessible for the average person looking to increase their privacy, and makes it trivial (if left on its default port) for a snooping entity to block the traffic forcing you to fall back to plain text DNS and leak your internet history once more.
Just like DoH, the destination server that you choose to use could potentially be logging your requests, so if privacy is truly your concern then you would be best served by choosing a server that you own or trust. Using port 443 instead of the default to avoid detection / blocking of the protocol is also an option.
This is the unsung hero of the DNS encryption world. For some reason it’s not brought up in the debate about privacy versus security, even though it appears to be the most used protocol among the three. For context, on the networks we monitor, DNSCrypt represented 0.1% of total DNS traffic at best, while DoH and DoT were between 1-3 orders of magnitude less. .
Prying eyes can only identify DNSCrypt if their tools parse the protocol
The default port is 443, using both TCP and UDP. The biggest difference is that DNSCrypt is its own protocol — it doesn’t work on top of TLS or HTTPS. This means that it can be identified and blocked at an application layer. Similarly to DoT, you’ll need third party software to use DNSCrypt: dnscrypt-proxy, which makes it less accessible to those seeking privacy. And just like the other two protocols, the destination server can log and do whatever it wants with your requests. DNSCrypt, however, does offer a solution: Anonymized DNSCrypt. This sends a DNSCrypt request to a proxy DNS relay, which then anonymizes and relays the request to a DNSCrypt compatible server. This gives the user an extra layer of privacy by ensuring that “Big DNS” doesn’t have your data.
In the next post in this series, we will talk about the security implications of these different mechanisms to achieve encrypted DNS.
Dig Deeper with These Resources
Awake Security 2 Minute Explainer Video
What if security could think? What if it could sense danger, calculate risk, and react quickly based…
Real World Incidents Detected and Stopped by Awake
Organizations across industries use Awake every day to identify and stop modern threats from both internal and…