DNS Over HTTPs and security aspects from individual and enterprise

What is DNS Over HTTPs (DoH)?

Standard DNS (on tcp/udp port 53) works just fine but missing security features to prevent tampering of its plaintext DNS request to the DNS providers. It leads to security issues such as DNS Cache Poisoning and typo-squatting domains.

DNS Over HTTPs (DoH) brings TLS/SSL encapsulation on HTTP traffic to boost security integrity issues of spoofing and tampering of DNS requests from clients to providers. In this article, i will refer DNS Over HTTPs as DoH abbreviation.

The Good

This brings better security for personal home network to prevent DNS based attacks and sniffing by attackers. You can find many DoH supported upstream providers and browser like Firefox already added this functionality in 2019 and started rolling out. There are project that showing the possibility to set up DoH server and set up pi-hole to relay DoH instead of standard DNS.

In general, this sounds like a good idea for individual users since it improves security of the DNS requests, however security professionals are pointing out caveats and challenges in enterprise network. Existing DNS security solution like DNS Sinkhole (which already have other issues) needs a redesign to support both DoH traffic and standard DNS traffic as fallback DNS request.

The Bad

Enterprise network relies network security control and monitoring using standard DNS traffic and containment of malicious domains via DNS security solutions and sink-holing.

There is SEI post from Carnegie Mellon University talks on 3 aspects to fight back risks bring from DoH. I want to comment on the points that we need to consider during executing these strategies:

Strategy 1: Disable DoH in Managed Endpoints.

• It is a plausible control to restrict configuration of DoH on applications to to whitelist applications if this aligns with organization security policies.

Strategy 2: Block Known DoH Providers for Managed and Unmanaged Endpoints.

• This is a bit of whack-a-mole approach to block DoH upstream DNS provides. As of 2022, even Google have DoH endpoints and if the enterprise solution starts using DoH on its products, admin going to need to whitelist these providers and this make things messier.

The Ugly

Strategy 3: Assume Breach and Focus on Detection.

• A secure way to establish DNS traffic brings unwanted audience whom are adversaries that are constantly seeking a better way to perform anomalous activities. To be able to detect DoH traffic among other HTTP, it needs a rethink of SIEM log collection and detection engineering as the start:
  • Security Operation needs to think of log collection to distinguish DoH traffic to merge in standard DNS traffic data model. RFC-8484 also describes the protocol description and implementation details. There is already academic paper in researching a initial analysis on DoH traffic identification.
  • The following code snippets is HTTPS GET/POST requests and example response from DoH server. It shows what “application/dns-message” is the keyword to identify DoH Traffic.

    # HTTP GET Request Sample of DoH traffic
    :method = GET
       :scheme = https
       :authority = dnsserver.example.net
       :path = /**dns-query**?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
       **accept = application/dns-message**
  

    # HTTP POST Request Sample of DoH traffic
    :method = POST
       :scheme = https
       :authority = dnsserver.example.net
       :path = /dns-query
       accept = application/dns-message
       **content-type = application/dns-message**
       content-length = 33
      
       <33 bytes represented by the following hex encoding>
       00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
       07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
       01
  

    # HTTP Response Request Sample of DoH traffic
    :status = 200
       **content-type = application/dns-message**
       content-length = 61
       cache-control = max-age=3709
      
       <61 bytes represented by the following hex encoding>
       00 00 81 80 00 01 00 01  00 00 00 00 03 77 77 77
       07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 1c 00
       01 c0 0c 00 1c 00 01 00  00 0e 7d 00 10 20 01 0d
       b8 ab cd 00 12 00 01 00  02 00 03 00 04
  

  • Think of a way to include DoH traffic in TLS interception to have visibility of DoH traffic.
  • Detection engineer and Threat intel analyst requires to sit down together how to include existing detection use cases and upcoming scenarios to include DoH traffic.
  • Monitor new TTPs and approaches used by adversary to have a detection strategy to prevent potential attacks to the organization.

  There are concerns and discussion in cybersecurity community on how to handle the risks of DoH with security controls. The protocol itself is in the early stage and there is still time for preparing to monitor and detect DoH traffic used by adversary. I’ll write up on a specific procedural mitigation actions that security professionals can exercise.