Using BreakingPoint to Test DNS over HTTPS (DoH) Services - Part 1
By Vincent Du | Part 2 of this blog series is here.
The DNS over HTTPS (DoH) protocol aims to address vulnerabilities found in existing DNS services, providing privacy and further avoiding internet censorship via DNS resolving. Google, Mozilla, CloudFlare, and the like have already published DoH services for the public to use.
For example, https://dns.google (8.8.4.4) is Google’s test DoH project. Developers can use two different URIs to access it:
- RFC8484 uri: https://dns.google/dns-query? (GET and POST)
- JSON API uri: https://dns.google/resolve? (GET)
The Keysight’s BreakingPoint system now can emulate network activities of both types of DoH services, with these four superflows:
- DNS over HTTPS
- DNS over HTTPS(JSONAPI)
- DNS over HTTP2
- DNS over HTTP2(JSONAPI)
Setting up back-to-back DoH tests (2-armed) with these Superflows is easy. With some extra effort, we were able to create a 1-armed test where BreakingPoint acts as a DoH client to request DNS service from an actual DoH server. Here we’d like to share our approaches.
Network Neighborhood and Test Setup
For DoH ClientSim to work, one interface of BreakingPoint must have a route to the target DoH server host, in our case, it must be connected to the internet. A Network Neighborhood (NN) like this will allow the “Interface 1” behind gateway 10.36.128.1 to communicate directly with dns.google (8.8.4.4)
Next, create a test with “Client Simulation” using this NN:
Create a load profile, load one of the DoH Superflows, then modify the native 2-armed DoH Superflow by removing all the actions originated from the server since it will be a ClientSim.
In the “Start TLS” action, some parameters need to be correctly set. It seems dns.google requires an ECDHE cipher, so include one like “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”, otherwise the TLS handshake will not succeed. Make sure the “Server Name Indication” field is set to the DoH service host also.
Lastly, reserve the single interface that has a connection to the target DNS host and make sure the Component Tags are set properly:
This test can now run and finish successfully.
From the packet capture, we can see that BreakingPoint has successfully finished the TLS handshake with the DoH host, and exchanged some messages with it.
The question now is, how do we know the encrypted TLS application data from the DoH server are the desired DNS query result? Also, due to the fact that an ECDHE cipher is used in the encryption, decryption with a MITM proxy becomes difficult.
In part 2 of this blog, I will introduce a method to allow viewing the server response in cleartext.
Superflows associated with DoH are available from Keysight’s Application and Threat Intelligence (ATI) subscription service in the 2019-18 Update on September 24.
