Using BreakingPoint to Test DNS over HTTPS (DoH) Services - Part 2
By Vincent Du | Part 1 of this blog series is here.
Decrypting TLS
BreakingPoint users can easily verify the client-side SSL traffic in a separate test with TLS actions removed from the DNS over HTTPS (DoH) Superflows. To decrypt the actual DoH traffic from the server-side, a “Raw” flow and three actions - “delay”, “conditional request”, and “raw” are added into the test ClientSim Superflow.
The “Raw” flow uses UDP as the L4 Transport:
The “Conditional Request” will match everything from the server-side by using regex “([\x00-\xff]+)” and a “goto” statement pointing to the “Raw Message” action upon regex match:
The “Raw Message” is an action belonging to the “Raw” flow that uses UDP; the “string” field is a token “##bpsvar(0)##” that will match and extract every byte from the previous action:
The PCAP of this test should have a UDP packet sent out by the client right after the DoH server-side application data, which is the cleartext of the DoH server response. The actual DNS response is in the HTTP payload. In our test, one response starts with “4b fe 81 80” (“4b fe” is the message ID, and “81 80” is the QR with response bit set, OPCode, AA, TC fields all being 0, and RD field being 1).
Decoding Gzip and Chunked
Next, we used “DNS Query over HTTPS(JSONAPI)” query action to repeat the test. Observing the UDP packet, we noticed that the HTTP payload is not the JSON message as we expected. But why?
Further inspecting the HTTP headers in the UDP payload we found “Content-Encoding: gzip” and “Transfer-Encoding: chunked”. With this information, we can decode the payload. For some reason, the DoH server is not responding to every DNS query with the desired answer. However, we know “1f 8b” is the magic byte for gzip, so searching for a UDP packet with it would lead us to the right packet to decode.
After we located the right UDP packet containing the DoH server response, we can copy the “Hex Stream” by right-clicking the packet in Wireshark, then select “Copy -> Bytes -> Hex Stream”:
Ruby IRB can be used to decode the payload hex stream. We know ‘1f 8b’ is the start of the gzip chunk, and there should always be a chunk with 0 length in the end, so the actual payload are the bytes between “1f 8b” and “00000d0a0d0a”.
With these commands in IRB to perform the decode, we can see the JSON message in the end.
Comparing this JSON object with a query made from cURL client or web browser to resolve “example.com” host, we can confirm the dns.google responded to the BreakingPoint DoH ClientSim test with exactly the same data.
LEVERAGE SUBSCRIPTION SERVICE TO STAY AHEAD OF ATTACKS
The Keysight BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.