Oblivious DoH : Enhanced DNS Privacy
2021-03-12 | 7 min read
Oblivious DNS Over HTTPS (ODoH)
Oblivious DNS Over HTTPS (ODoH) is a newly proposed open-source DNS standard built by engineers from Cloudflare, Apple, and Fastly which is supposed to increase the privacy of already existing DNS Over HTTPS (DoH).
Problem with Existing DNS Over HTTPS (DoH)
Although DNS over HTTPS, solves the issue of interception of traditional plain text DNS by using HTTPS, a problem still persists i.e., the query is available in clear text to the resolver and also the resolver knows the IP address from where the query is coming. Since the resolver usually belongs to a particular company, it’s up to them what to do with the user’s data. That’s the issue, ODoH is trying to address.
Oblivious DNS Over HTTPS (ODoH)
The way that ODoH is different from traditional DoH is by the inclusion of a third entity (proxy) between the client and the DNS resolver. It also includes an additional layer of encryption. To address the above-discussed issue of DoH, DNS request is first sent to the proxy, which the proxy then forwards to the resolver. So by doing this, although the resolver knows the plain text query that was being sent, it doesn’t know the client IP address, as it was forwarded by the proxy.
Now, one question that might arise is that wouldn’t the proxy be able to see both the query and the client IP address? This is addressed by the additional layer of encryption, Hybrid Publick Key Encryption (HPKE ) that ODoH has, where the query before being sent to the proxy is encrypted with the resolver’s public key so that only the resolver can see the plain text query. So as long as both the proxy and the resolver don’t collude, privacy is maintained. Also, the client packs a symmetric key in the encrypted query, which is used for encryption and decryption of the response.
Below is a pictorial representation of the working of ODoH.
Cloudflare has released both the client and server deployments of ODoH in Github for developers and researchers to test them out. Let’s check them out!
Deployment of ODoH Client
- Download the ODoH Client code from here. Or do - " git clone https://github.com/cloudflare/odoh-client-go.git "
- Inside the odoh-client-go folder, run – " go build -o odoh-client ./cmd/... "
- This should give us the odoh-client.
Deployment of ODoH Server
- Download ODoH Server from here. Or do – " git clone https://github.com/cloudflare/odoh-server-go.git "
- Inside the odoh-server-go folder, Run – " go build "
- This will give us the odoh-server.
- We need CADDY, a reverse proxy that will handle all the TLS connection requirements. Run the below commands to install and configure Caddy for our purpose -
- " sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https "
- " curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/cfg/gpg/gpg.155B6D79CA56EA34.key' | sudo apt-key add - "
- " curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/cfg/setup/config.deb.txt?distro=debian&version=any-version' | sudo tee -a /etc/apt/sources.list.d/caddy-stable.list "
- " sudo apt update "
- " sudo apt install caddy "
- " sudo systemctl stop caddy "
- " sudo caddy reverse-proxy --from 127.0.0.2:443 --to 127.0.0.1:8080 "
- From the odoh-client-go directory, Run this – "./odoh-client odoh --domain www.google.com. --target 127.0.0.2:443 --dnstype A --proxy 127.0.0.2:443 "
- We should get a response like this –
- The same server seems to be able to handle doH queries too!
- On using Wireshark to see the traffic, we can see that when the request is being sent to the proxy, the actual response is encrypted, so that proxy can’t take a look in to it.
- After the request reaches the actual target, behind the scenes the target resolves the query using the traditional DNS protocol.
NOTE – There seems to be some issue with our configuration due to which some packets are visible in cleartext. If you query the actual Cloudflare server with this client, you won’t be seeing this info, everything would be encrypted.
- There is an additional layer of encryption that ODoH is doing, compared to DoH, that might lead to performance issues, but according to Cloudflare's initial round of testing, they found the performance tradeoff is marginal, although more testing at the global level is to be seen.
- There are added costs for proxy deployments and added encryption that will happen here.
Use BreakingPoint and the other Keysight Application and Threat Intelligence (ATI) products to test your devices for these types of applications.
Released in the recent Strikepack update 2021-05, our implementation of ODoH are 2-arm superflows where the client fetches ODoH configs through proxy and sends an ODoH query to the resolver through proxy and receives the response. Superflows have an ample amount of customization through parameters to customize the traffic for your needs.
BreakingPoint also has a wide range of other applications and attacks that you can send together over the wire, allowing for more robust testing of the DUT.