Encrypted Traffic Analysis: Encrypted DNS – Privacy, Security and the SOC (Part 2)
Security Implications of Encrypted DNS
This is the second post in a three post series discussing the implications of encrypted DNS on privacy and security — this one will be focused on the later. If you missed the first post, you can find it here.
DNS over HTTPS (DoH)
This protocol has been labeled as the less security focused option when compared to DNS over TLS (DoT). This is mainly due to two factors: it operates in the browser, and it uses the same port and protocol (443 and HTTPS respectively) to communicate. This makes it difficult to prevent users from using it (since they don’t have to install third party software), and impossible to block based on port or application layer without also interrupting a majority of other web traffic on your network.
Many browsers support DoH and Firefox now enables it by default. There is an option for network administrators to set up a canary domain internally to disable DoH in Firefox, but if a user has manually enabled it, then this is inconsequential (anyone that wants to monitor traffic could do the same thing). Users can also download a DNS proxy to use DoH system-wide, but that requires admin access on their devices.
The ease of use and the fact that it is the default in a popular browser makes it a unique challenge for security practitioners. Not only could it be used to bypass controls (either to circumvent compliance policy, or by a malicious actor), but if it is being used on your network it could inadvertently conceal the destination of an attack vector such as a user clicking a link in a phishing email.
DNS over TLS (DoT)
The reasons why DoT is preferred by the security minded is because it uses a different default port (853) and it requires the installation of third party software. The former can be used to block DoT network-wide by blocking that port. However if a port that isn’t blocked is used (such as 443), that won’t work. The latter helps prevent usage since existing security controls often prevent users from installing unapproved software.
In my opinion, DNSCrypt should be even more preferable by the security community in most cases. The major difference is that it uses its own protocol, so if you have the ability to parse and identify the protocol, then you can identify and block it that way. Identifying things based on protocol is more reliable than identifying them based on ports, since you can use any port for anything. For instance, as mentioned above DoT can be used on port 443 to circumvent. But with DNSCrypt, you can still identify it at the application layer.
Also like DoT, DNSCrypt requires the installation of third party software. This means that unless your network security stack is unable to recognize DNSCrypt, most security practitioners would rather have DNSCrypt on the network than DoT or DoH. If your only option is blocking at the port level it’s a tie between DNSCrypt and DoT.
Until next time
Unlike those focused on increasing privacy, the infosec community doesn’t get to pick which of these protocols are used on their networks; there’s the potential for any of them to crop up. In the next post in this series we will discuss how to use the information shared in the first two posts to detect and respond to DNS encryption even when you cannot block or prevent it entirely.
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…