DoH, DoT and ESNI

Editor's Notes

1. Incident Response Consultant for Nettitude, a security consultancy firm here in the UK. Previously I was with BT for two years in their 3rd Line CERT, where some of you may recognize me from. I was fairly active in the TF-CSIRT/FIRST scene, with a few presentations: Scanning for vulnerable Amazon AWS S3 buckets, & Google cloud (and a little bit of Azure) Tracking APT28 with their OPSEC fails with just OSINT tools and data SMB Honeypot activity, detailing how prolific EternalBlue is on the Internet. Today however, I’d like to talk to you all about DNS. Specifically, DoH, DoT and the future of eSNI.
2. Browser checks its local cache for bbc.co.uk and its resulting IP address. Checked the local OS cache for bbc.co.uk Goes off to the next DNS Resolver (normally your ISP. Your network knows about this thanks to your ISP supplied router/modem). If our DNS Resolver doesn’t know, it goes off to the root DNS server to ask, where it is told about the nameserver for the TLD (in this instance, .co.uk). This info is cached by the DNS resolver, so that we don’t have to pester the 13 root servers again. If the TLD nameserver doesn’t know (i.e isn’t cached), it will provide the authoritative nameservers for the domain (ns3.bbc.co.uk, n3.bbc.net.uk). Again, this info is cached by the DNS resolver. Glue records are passed with the ns record, so that the resolver knows what IPs to talk to. The authoritative nameserver will hand out the IP address for bbc.co.uk, which is again cached by the DNS resolver. The record returned is likely to be an A record, simply a way of turning a domain into an IP address. Other records exist like MX for mail servers etc. DNS Resolver hands it back to our machine, and away we go.
3. Our DNS request packet, from the local machine to my next resolver (in this case, 192.168.1.1).
4. And the response back from 192.168.1.1, with a CNAME record, and 2 A records.
5. Here is a visual representation of that, where we can see all those comms in red are unencrypted and leak information about our behaviour. As we learned previously, DNS is all plaintext over UDP or TCP on port 53, so anyone can grab that off of the wire. We can also see the initial TLS handshake for the HTTPS connection is also unencrypted, leaking the SNI (server name indication) on the ClientHello, and CommonName in the ServerHello response. Very interesting information, which I’m sure many of us have used in the past to aid investigations where TLS interception isn’t being utilised or isn’t viable in the environment.
6. DNS over HTTPS (DoH) is one proposal on the table for solving some of the pitfalls of the traditional DNS resolution that underpins the Internet. The key issues being addressed in current DNS are the end user privacy implications and the possibility of Man-in-the-Middle (MitM) attacks which mean that a malicious party within the data path of resolution could interfere with the messaging. The DoH solution, described in RFC8484 ( https://tools.ietf.org/html/rfc8484), sees the sending of DNS queries and retrieval of DNS responses take place over HTTPS which provides security for integrity and confidentiality. In this DNS ecosystem DoH providers host a URI endpoint on the Internet that facilitates DNS resolution. An alternate approach to DoH is DNS over TLS (DoT), described in RFC7858 ( https://tools.ietf.org/html/rfc7858), but this approach requires direct outbound connectivity to port TCP 853.
7. DNS over HTTPS (DoH) is one proposal on the table for solving some of the pitfalls of the traditional DNS resolution that underpins the Internet. The key issues being addressed in current DNS are the end user privacy implications and the possibility of Man-in-the-Middle (MitM) attacks which mean that a malicious party within the data path of resolution could interfere with the messaging. The DoH solution, described in RFC8484 ( https://tools.ietf.org/html/rfc8484), sees the sending of DNS queries and retrieval of DNS responses take place over HTTPS which provides security for integrity and confidentiality. In this DNS ecosystem DoH providers host a URI endpoint on the Internet that facilitates DNS resolution. An alternate approach to DoH is DNS over TLS (DoT), described in RFC7858 ( https://tools.ietf.org/html/rfc7858), but this approach requires direct outbound connectivity to port TCP 853.
8. Important thing to note, is that the DNS query (dns wire-format) is base64url encoded, not base64 encoded. That is an important thing to note, as it means certain base64 characters aren’t included (/, +). Padding (=) must not be included.
9. In this example, the 33 bytes are the DNS message in DNS wire format [RFC1035], starting with the DNS header. https://routley.io/tech/2017/12/28/hand-writing-dns-messages.html
10. Response back is once again in the DNS wire-format.
11. Response back this time in JSON!
12. How It Works: A stub resolver (the DNS client on a device that talks to the DNS resolver) connects to the resolver over a TLS connection: Before the connection the DNS stub resolver has stored a base64 encoded SHA256 hash of cloudflare-dns.com’s TLS certificate (called SPKI) DNS stub resolver establishes a TCP connection with cloudflare-dns.com:853 DNS stub resolver initiates a TLS handshake In the TLS handshake, cloudflare-dns.com presents its TLS certificate. Once the TLS connection is established, the DNS stub resolver can send DNS over an encrypted connection, preventing eavesdropping and tampering. All DNS queries sent over the TLS connection must comply with specifications of sending DNS over TCP.
13. Response back.
14. Left: Current day – Everything is encrypted from the ServerHello onwards… but ClientHello as we saw in the previous slide is sent in the clear. This is what we see in the ACP proxy logs, where TCP CONNECT manages to give us the SNI (i.e. the subdomain and domain, but not the URL query etc.) Right: Potential future, where everything is encrypted end to end. Our best bet is to look at IP addresses and netflow (but the issue here is that the internet is no longer 1 IP = 1 website, we have shared hosting and services like Cloudflare and CDNs which means we never really see the end destination). If the chicken must come before the egg, where do you put the chicken? As with many other Internet features the answer is simply “DNS”. The server publishes a public key on a well-known DNS record, which can be fetched by the client before connecting (as it already does for A, AAAA and other records). The client then replaces the SNI extension in the ClientHello with an “encrypted SNI” extension, which is none other than the original SNI extension, but encrypted using a symmetric encryption key derived using the server’s public key, as described below. The server, which owns the private key and can derive the symmetric encryption key as well, can then decrypt the extension and therefore terminate the connection (or forward it to a backend server). Since only the client, and the server it’s connecting to, can derive the encryption key, the encrypted SNI cannot be decrypted and accessed by third parties.
15. The future. What will we see? A connection to 1.1.1.1 or 8.8.8.8 etc. over HTTPS, and a connection to another IP address – that’s it.
16. Response back this time in JSON!
17. Response back this time in JSON!
18. Today? No idea, but its probably very hidden and be a pain to go and spot. goDoH is a C2 framework written in Golang, utilising DNS over HTTPS as a transport medium. Every redteamers favorite toy also now has C2 channel out via DNS over HTTPS Ngrok is currently doing DNS over HTTPS, which has been spotted a couple of times on VT by various researchers.
19. Monitoring for traffic to the DoH endpoints will provide you a view of whether or not it is happening on your estate, but obviously won’t provide you with the DNS logs we are used to, to see what people have been looking up. Inspecting the headers would work if you’re MITM/TLS Stripping all of your internal traffic, which some corps ofcourse do. Our best bet, like with most encrypted communications, is to use the metadata and heuristics to try and interpret what is going on. NCSC EU have produced a very useful factsheet on monitoring DNS with DoH and DoT on the horizon.
20. JA3 - A method for profiling SSL/TLS Clients JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence. We can see Justin Warner here has already put two separate PCAPs through JA3, for both Google DNS and Cloudflare, and successfully fingerprinted the browser client. The issue here however, is this will vary greatly depending on OS and browser version, which leads to the classic problem of large amount of data for an analyst to work through, or attempting to maintain a lengthy whitelist/fingerprint list.
21. JA3 - A method for profiling SSL/TLS Clients JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence. We can see Justin Warner here has already put two separate PCAPs through JA3, for both Google DNS and Cloudflare, and successfully fingerprinted the browser client. The issue here however, is this will vary greatly depending on OS and browser version, which leads to the classic problem of large amount of data for an analyst to work through, or attempting to maintain a lengthy whitelist/fingerprint list.