Downloaded 40 times
![RFC8484: DNS over HTTPS (DoH)
RFC8484
Confidential Information 9
RFC8484 defines a specific protocol, DNS over HTTPS
(DoH), for sending DNS [RFC1035] queries and getting
DNS responses over HTTP [RFC7540] using https
[RFC2818] URIs (and therefore TLS [RFC8446] security
for integrity and confidentiality). Each DNS query-
response pair is mapped into an HTTP exchange.](https://image.slidesharecdn.com/day2-grahamstevens-gateshead1-191107110953/85/DoH-DoT-and-ESNI-9-320.jpg)
![So what does it look like? JSON
ConfidentialInformation 14
Request
curl -k -H "accept: application/dns-json"
https://dns.google.com/resolve?name=example.com&type=AAAA
Response
{"Status": 0,"TC": false,"RD": true,"RA": true,"AD":
true,"CD": false,"Question":[ {"name":
"example.com.","type": 28}],"Answer":[ {"name":
"example.com.","type": 28,"TTL": 6410,"data":
"2606:2800:220:1:248:1893:25c8:1946"}]}](https://image.slidesharecdn.com/day2-grahamstevens-gateshead1-191107110953/85/DoH-DoT-and-ESNI-14-320.jpg)
![RFC7858: DNS over TLS (DoT)
RFC7858
Confidential Information 15
RFC7858 defines a protocol, DNS over TLS (DoT), for
sending DNS [RFC1035] queries and getting DNS
responses using TLS [RFC8446] for integrity and
confidentiality.
Port 853 outbound is required for DoT, similar to how 53 is
required for ‘classic’ DNS.](https://image.slidesharecdn.com/day2-grahamstevens-gateshead1-191107110953/85/DoH-DoT-and-ESNI-15-320.jpg)
Uploaded byJisc
DoH, DoT and ESNI
The document discusses DNS over HTTPS (DoH), DNS over TLS (DoT), and Encrypted Server Name Indication (ESNI). It explains that DoH and DoT encrypt DNS queries and responses for increased privacy and security compared to traditional DNS. However, ESNI is also discussed as a solution to further improve privacy by encrypting the server name in the TLS handshake. Concerns about the potential use of these protocols by malware for command and control are also raised.
More Related Content
DoH, DoT and ESNI
- 1. DoH, DoT, &ESNI Graham Stevens
- 2. DoH, DoT, &ESNI DNS over HTTPS DNS over TLS EncryptedServer NameIndication GrahamStevens–6th November2019
- 3. whoami • Graham Stevens •IncidentResponse Consultant • gstevens@nettitude.com ConfidentialInformation 3
- 4. DNS in 60Seconds ConfidentialInformation 4 bbc.co.uk Root TLD NS
- 5. What this lookslike on the wire ConfidentialInformation 5
- 6. What this lookslike on the wire ConfidentialInformation 6
- 7. So what’s wrongwith that? ConfidentialInformation 7 • RFC 1034 &RFC 1035 • Firstintroducedin1985. • Poorsecurity(no cryptographicsignaturesonthe responses,socould havebeen tamperedwith) • Poorprivacy(Everythingisincleartext)
- 8. So what’s wrongwith that? ConfidentialInformation 8 DNSProvider DNS PlaintextoverUDP/TCP DNSQuery www.bbc.co.uk 151.101.0.81 server_name: www.bbc.co.uk CommonName: www.bbc.co.uk TLS1.2 Orlower bbc.co.uk TLS<= 1.2 HTTP Unencrypted Encrypted DNSResult
- 9. RFC8484: DNS overHTTPS (DoH) RFC8484 Confidential Information 9 RFC8484 defines a specific protocol, DNS over HTTPS (DoH), for sending DNS [RFC1035] queries and getting DNS responses over HTTP [RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446] security for integrity and confidentiality). Each DNS query- response pair is mapped into an HTTP exchange.
- 10. That’s great but…so what? ConfidentialInformation 10 • NomoreUDPpackets. • HTTP– A protocolwe allknow and love. • GET &POST bothaccepted • DNSwire-formatorJSON • Enforcedend-to-end encryptionwiththe widelyadoptedTLS
- 11. So what doesit look like? ConfidentialInformation 11 GET Request :method = GET :scheme = https :authority = dnsserver.example.net :path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB accept = application/dns-message
- 12. So what doesit look like? ConfidentialInformation 12 POSTRequest :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
- 13. So what doesit look like? ConfidentialInformation 13 Response This is an example response for a query for the IN AAAA records for "www.example.com" with recursion turned on. The response bears one answer record with an address of 2001:db8:abcd:12:1:2:3:4 and a TTL of 3709 seconds. :status = 200 content-type = application/dns-message content-length = 61 cache-control = max-age=3709 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
- 14. So what doesit look like? JSON ConfidentialInformation 14 Request curl -k -H "accept: application/dns-json" https://dns.google.com/resolve?name=example.com&type=AAAA Response {"Status": 0,"TC": false,"RD": true,"RA": true,"AD": true,"CD": false,"Question":[ {"name": "example.com.","type": 28}],"Answer":[ {"name": "example.com.","type": 28,"TTL": 6410,"data": "2606:2800:220:1:248:1893:25c8:1946"}]}
- 15. RFC7858: DNS overTLS (DoT) RFC7858 Confidential Information 15 RFC7858 defines a protocol, DNS over TLS (DoT), for sending DNS [RFC1035] queries and getting DNS responses using TLS [RFC8446] for integrity and confidentiality. Port 853 outbound is required for DoT, similar to how 53 is required for ‘classic’ DNS.
- 16. So what doesit look like? ConfidentialInformation 16 $ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com ;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP) ;; DEBUG: TLS, imported 170 system certificates ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com ;; DEBUG: SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= ;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA ;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GC ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR ;; PADDING: 408 B ;; QUESTION SECTION: ;; example.com. IN A ;; ANSWER SECTION: example.com. 2347 IN A 93.184.216.34
- 17. So where doesthat leave us? • DNSis no longer is clear text • End-to-end encryptionwith HTTPS • But we still havea privacy leak: • ClientHello • server_name ConfidentialInformation 17
- 18.
- 19.
- 20. So what’s wrongwith that? ConfidentialInformation 20 DNSProvider DNS OverHTTPS/TLS DNSQuery 151.101.0.81 TLS1.3 WithencryptedSNI bbc.co.uk TLS1.3 HTTP Unencrypted Encrypted DNSResult
- 21. Usage as ofToday ConfidentialInformation 21 DoH Firefox –Gradualrolloutduring2019/20 inUSasdefault. Chrome –Gradualrollout asofChrome78, basedoncurrentDNSprovider. cURL –Availablesince7.62.0. $ curl --doh-url https://dns-server.example.com https://www.example.com DoT Android –As ofAndroidPie (August 2018)
- 22. Scary Thoughts… ConfidentialInformation 22 Whathappenswhenmalware utilisesESNI &DoH? Open-sourceimplementationsarealreadyfreelyavailable: • DNSC2 by Sensepost(https://github.com/sensepost/goDoH) • DNSC2 for CobaltStrike (https://github.com/SpiderLabs/DoHC2) • Alreadyhappening: https://github.com/magisterquis/dnsbotnet • ImplementedDNSoverHTTPS/DomainFrontinginMay2018. • dnscat2:(https://github.com/iagox86/dnscat2)
- 23. Scary Thoughts… Today! ConfidentialInformation23 DoHisactivelybeingusedby malwaretoday. • April2019 –Godlua Backdoor usesDoHforC21 • June 2019 – ReportsofNecursusingDoH2 • September2019 – PsiXBotabusesGoogle’s DoHServiceforC23 • October2019 – mimikatz.exe overDoH(TXTrecords)4 1 https://blog.netlab.360.com/an-analysis-of-godlua-backdoor-en/ 2 https://myonlinesecurity.co.uk/it-looks-like-another-dns-compromise-hack-happening/ 3 https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module 4 https://twitter.com/DidierStevens/status/1152971745428738049
- 24. What can wedo about it? ConfidentialInformation 24 • Blockormoreaggressivelymonitortrafficto DNSoverHTTPS(DoH)endpoints.If youwishtobenefitfromsomeofthe security benefitsthat DoHoffers,rollout internalDoH,DNSoverTLS(DoT) resolversand/orcarryout secureDNSresolutiononthe outermostDNSserversofthe organisation. • WherepossibleinspectunderlyingHTTP exchangesforindicatorsof DoHusewhereTLSisstrippedforinspectionwithinan organisation.i.e. 'application/dns-json','application/dns-message'contenttypes. • Apply heuristicbasedoranomaly-baseddetectionsofpacket sizes,frequencyand volume,timebased,patternoflifetooutgoing traffic. • NCSC Factsheet • https://english.ncsc.nl/publications/factsheets/2019/oktober/2/factsheet-dns-monitoring-will-get-harder
- 25. What can wedo about it? ConfidentialInformation 25 • Apply heuristicbasedoranomaly-baseddetectionsofpacketsizes,frequencyandvolume,timebased,patternoflifeto outgoing traffic. • Possibletoutilise Saleforce’sJA3 (https://github.com/salesforce/ja3) CourtesyofJustinWarner(@sixdub)
- 26. Further Reading ConfidentialInformation 26 •EncryptedSNI • https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 • DNSoverHTTPS • https://tools.ietf.org/html/rfc8484 • DNSoverTLS • https://tools.ietf.org/html/rfc7858 • DNSwrittenbyhand • https://routley.io/tech/2017/12/28/hand-writing-dns-messages.html
- 27.
- 28. Thank you customerservices@jisc.ac.uk jisc.ac.uk Graham Stevens IncidentResponse Consultant gstevens@nettitude.com
Editor's Notes
- #4 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.
- #5 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.
- #6 Our DNS request packet, from the local machine to my next resolver (in this case, 192.168.1.1).
- #7 And the response back from 192.168.1.1, with a CNAME record, and 2 A records.
- #9 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.
- #10 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.
- #11 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.
- #12 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.
- #13 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
- #14 Response back is once again in the DNS wire-format.
- #15 Response back this time in JSON!
- #16 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.
- #17 Response back.
- #20 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.
- #21 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.
- #22 Response back this time in JSON!
- #23 Response back this time in JSON!
- #24 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.
- #25 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.
- #26 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.
- #27 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.