Is It Possible for Encryption to Harm Cybersecurity?

Context

The Domain Name System (DNS) is the directory of the World Wide Web, converting URLs into IP addresses in order to allow software to locate content. In addition to acting as a simple directory, some network operators use the DNS as a control mechanism to restrict access to certain content, for example using parental controls, malware filtering and other options. This applies to both ISPs offering services over public networks and enterprises running their own private corporate networks and can apply to content deemed, for example, unsuitable, illegal or malicious.

A relatively recent development in DNS protocols has enabled DNS traffic to be encrypted (see below for a short explanation), making such control mechanisms harder to implement. The motivation behind these developments appears to be a combination of concerns about user privacy as well as application (particularly browser) performance.

A second notable development has been the rise of cloud-based public resolvers, with examples being those operated by companies such as Google, Cloudflare and Quad9. Traditionally DNS services have mainly been provided by ISPs to their customers, but these cloud-based resolvers have offered an alternative option, one that seems primarily to have attracted the attention of more technically knowledgeable users rather than being a mass-market option.

Some have welcomed the emergence of these independent resolvers as it provides greater choice and enables them to overcome what they regard as the restrictive filtering policies adopted by their ISPs (NB these are often driven by the need to comply with regulatory requirements). A downside to these resolvers being used is that network operators may lose visibility of the characteristics of network traffic, affecting their ability to manage security risks and quality of service.

What is Encrypted DNS?

With the traditional DNS protocol, any requests from a device are routed to resolvers in plain text, allowing a third party to observe the activities of a user and potentially alter the results of their queries so that they receive false data.

With one of the encrypted DNS protocols, for example DNS-over-HTTPS (“DoH”), the data is encrypted, stopping a third party from easily observing or altering the queries.

It should be remembered that any client software can opt to use encrypted DNS if support has been added by its developers. Some options, including DoH, allow the software to make DNS queries directly, potentially bypassing any user or system preferences. In addition, although the queries are encrypted to protect them from third parties, the operator of the resolver still has full visibility of both the queries and their origin.

Approaches to Upgrading to Encrypted DNS Protocols

With the emergence of encrypted DNS protocols, a range of approaches have been taken to encourage their adoption by different software companies. For example, one of the earliest proponents of encrypted DNS was Mozilla through its Firefox browser. In the US, Firefox automatically encourages users to switch from their current resolver to an encrypted one that is operated by a company that is compliant with Mozilla’s Trusted Recursive Resolver policy.

An issue with this approach is that it assumes that the recommended resolvers offer improved protection versus the one currently being used. In reality, the existing resolver may support one or more encrypted DNS protocols and the connection may already be encrypted. In such circumstances, it is possible that the existing resolver may provide protections not offered by all of those recommended via the Mozilla programme; for example, the default resolver operated by Cloudflare does not offer malware filtering.

An alternative approach implemented by companies such as Google (for its Chrome browser) and Microsoft (for Windows 10+) is known as “same provider, auto-upgrade” (SPAU). The software detects the resolver currently being used and, if it uses the unencrypted DNS protocol, compares it to a lookup table. If the operator of the current resolver also offers an encrypted DNS option, the software will automatically switch to this. Because the same resolver operator is being used, any existing options set by the user should be retained.

Whilst SPAU has advantages compared to the approach used by companies like Mozilla, it relies on a curated list maintained by each software developer. Work is well advanced within the Internet Engineering Task Force (IETF), the relevant standards body, to develop a number of standards-based approaches to enable software to discover encrypted DNS resolvers using different protocols without having to maintain lists using manual processes. A relatively straightforward discovery mechanism, called Discovery of Designated Resolvers (DDR) has already had early deployment by a number of companies including Cisco, Microsoft, Quad9, Cloudflare and Apple. A more sophisticated option, called Discovery of Network-designated Resolvers (DNR) is also moving forward and seems better suited to the needs of network operators and others.

Other Options?

The above approaches all enable the DNS queries and their response to be encrypted and therefore obscured from observers. However, as already noted, the operator of the DNS resolver is still able to read the queries and match them to the originating device, enabling user activity to be tracked. Other developments seek to break this link.

One example is known as Oblivious DoH, which builds on the DNS-over-HTTPS protocol by adding two proxies. When the first proxy receives an encrypted DNS query from a user, it is passed without being opened to a second proxy; the second proxy decrypts the DNS query and passes it to a resolver before encrypting the response and passing it back to the first proxy which relays it to the originating device. This mechanism is used by Apple’s Private Relay service.

In the above scenario, the first proxy has no knowledge of the actual DNS queries, the second has no knowledge of their origin. The resolver operator is insulated from the end user by the proxies, removing its ability to track user activity, albeit at the potential cost of some additional latency. However, the privacy gains of Oblivious DoH can be defeated if the two proxies are not independent of each other but instead collude. In this case, the user may have the illusion of privacy but may in reality be open to tracking and other attacks.

Do Encrypted DNS Protocols Ensure DNS Queries are Private?

The above text outlines how the original, plaintext DNS protocol is being encrypted. However, one of the gaps this leaves open is the Server Name Indication (SNI) data, which allows multiple sites to be hosted at the same IP address, with the SNI data being used to identify which site the user wishes to access. Whilst DNS protocols like DoH encrypt the DNS queries, the SNI data leaves details of the domain names that are being accessed in plaintext.

Another development at the IETF standards body, called Encrypted Client Hello or ECH, builds on TLS 1.3 and DoH to encrypt the SNI data. This is intended to address the above weakness that is left when the DNS queries are encrypted.

Whilst having some privacy benefits, it should be noted that there are some drawbacks to the encryption of the SNI data. For example, in the same way that DNS can be used as a control mechanism for malware filtering, parental controls etc, SNI data is also used to support various services. Some of the more common users of the SNI data include:

• Schools and businesses to aid their content filtering policies
• Enterprises to allow bring your own device policies to be implemented in a relatively light-touch way
• Zero rating of specific content on broadband and mobile networks for users with data caps
• Cybersecurity in enterprises – the SNI data can be a very useful so-called “indicator of compromise” (ie it can help to detect unusual behaviour on a network that could be caused by, for example, malware).

The above list is not intended to be exhaustive but should serve to illustrate that encryption of the SNI data may have operational consequences.

The Unintended Consequences of the Encryption of DNS and SNI Data

Now we have this summary of some of the developments relating to the encryption of DNS and SNI data in place, the intended effect of these developments can be summarised very simply by the following diagram:

The basic premise of communication being allowed to take place without observation of interference is attractive. An alternative portrayal of some of the effects of this encryption is highlighted in the following diagram.

In other words, there may be unintended consequences that some will regard as undesirable. One group often mentioned as needing the protection offered by these and other techniques are dissidents, however it should be noted that a repressive state may counteract such measures by, for example, blocking any encrypted SNI data. There are in fact better tools for such categories or users, for example the Tor browser.

What are the Consequences in a Zero-Trust Environment?

In terms of security, best practice suggests use of the “Zero Trust” model, an approach where inherent trust between entities in a network is removed. For example, instead of assuming everything behind the corporate firewall is safe, the Zero Trust model verifies each request as though it originates from an open network.

Recent and current developments make the use of DNS and SNI data to monitor communications to and from applications increasingly difficult. In some cases, end users, device owners or network operators will retain the option to disable mechanisms such as the encryption protocols outlined above, but in other cases, it seems likely that the software developers will make these choices and provide options to over-ride their default settings.

In such circumstances, it will become difficult to differentiate the behaviour of benign software from that of malware on a device or network as it may not be possible to monitor inbound and outbound communications. In a corporate environment, this is likely to lead to such software being removed as it will be impossible for companies to maintain the security of their network and, in some cases, could lead to them breaching regulatory or other compliance obligations if they take no action. In such circumstances, the motivation for enterprises to act is significant. For example, although a slightly different scenario, there are indications that US regulators are in the process of levying fines of $200m each on a number of institutions because they were unable to track all communications by their employees because some were encrypted though the use of WhatsApp or Signal.

In a consumer environment however, it is likely that the vast majority of users will lack both the necessary knowledge and tools to identify potentially problematic behaviour by software. Because of this, it is possible that the development of protocols intended to safeguard privacy may instead exacerbate existing surveillance of user behaviour as it will be increasingly difficult for users to identify, let alone prevent, communication between the software on their devices and third parties. Malware developers and other unscrupulous software developers will exploit developments such as ECH to improve their activities, in much the same way that they did with encrypted DNS.

Conclusions

Whether the benefits of the encryption of DNS and SNI data are such that they outweigh the increased attack surface that they create remains to be seen. It certainly seems to be the case that insufficient consideration to these impacts is currently being given, with new approaches being developed without significant input from the various end-user communities, information security practitioners and others that may be affected.

_{Cover image by unknown author, licensed under CC BY-ND.}