Secure DNS (DoT and DoH) is not enough

Published on 17 February 2023
Updated on 28 November 2023

Secure DNS is necessary (and available)

Securing communications on the Internet became the norm in the last years. Especially for Web traffic thanks to various incentives from browser vendors to make HTTPS (i.e., HTTP over TLS) the default, and recent certificate authority organisms such as Let's Encrypt that provide TLS certificates for free to anyone.

Funnily enough, DNS has remained a little on the sidelines, despite the secure-all trend. And that, even though it is a critical service that we use before making the first HTTPS request.

Fortunately, DNS comes with two secure versions: DNS-over-TLS (DoT), and DNS-over-HTTPS (DoH). And here are some good news: DoT/DoH is not reserved for tech savvy people running Linux. Apple devices and Android 9+ devices support those natively, without hacks, without wizardry. (Apple devices: download and apply a profile; Android 9+: set up "Private DNS" in settings.)

Secure DNS is undermined by TLS SNI

So, everyone can enjoy a full privacy-friendly browsing experience, now? Well, not quite.

Suppose we want to visit https://lu.sagebl.eu/notes/secure-dns-dot-doh-is-not-enough/. We first resolve lu.sagebl.eu with DoT or DoH, then we establish a secure connection with the server, thanks to HTTPS.

Let's sniff our traffic with tcpdump and see what our ISP or VPN provider might see as well.

# tcpdump -A -v tcp port 443
[some stuff...]
[some stuff...]

10:24:56.168515 IP6 (flowlabel 0xed28e, hlim 64, next-header TCP (6) payload length: 549) lubox.58610 > [MY IPv6 REDACTED].https: Flags [P.], cksum 0x8a19 (incorrect -> 0xb36e), seq 1:518, ack 1, win 507, options [nop,nop,TS val 3412622254 ecr 1380950982], length 517
`....%.@ ..a?D....^.m..M&.G.07.......C.?..........L............
.h{.RO.............. .X2d93.......~v..O.LR..[..J.9- .^3./.`...r..^....`}$.oQ6CE.SiN..H.........,.0.......+./...#.'.
...	...........=.<.5./...........k.g.9.3.....k.........lu.sagebl.eu.........
...............................h2.http/1.1.........1.....". ...........	.
...................+........-.....3.&.$... ...........=zX.L....>.TR...\#i)@.......................................................................................................................................................................................

[some stuff...]
[some stuff...]

Did you see that? A wild lu.sagebl.eu appeared in clear text! (highlighted with bold font.)

This is because of the use of an extension to TLS, the Server Name Indication (SNI). SNI is pretty useful, it allows the client tell the server which site it wants to connect to, and which HTTP versions are supported (h2.http/1.1) during the TLS handshake. It's a bit like vhosts with HTTP Host header. It's necessary because a server hosting multiple HTTPS websites must present the correct certificate to the client, and a certificate is valid for a specific name (or a list of names) only.

Since all that happens during the TLS handshake, the secure (encrypted) connection is not set up at this point. So SNI info is plain text, resulting in leaking valuable information such as the name of the website.

Brighter future: Encrypted Client Hello

Fret not! People are aware of the situation, and new IETF standards have been proposed. Encrypted Client Hello (ECH) is a solid solution to the problem.

Cloudflare people wrote on ECH on the company tech blog, calling it the last puzzle piece to privacy. The article is a good place to start if you want to learn more on ECH.