Hacker News Reader

Comment by ck2 | Hacker News Reader

Is the idea behind encrypted DNS to stop manipulation of the answer given?

Because it can't be privacy, any ISP or router along the way can see the source/destination IP which is "naked" and basically has to always be?

View on HN

it is privacy. The ISP and routers can see the IP addresses but that gives a lot less info than the url since most websites will pull from a changing set of IPs due to server changes, cdns, and 3rd party content (e.g. ads). For a large number of sites, the IP addresses will just tell you that someone is looking at a website hosted by cloudflare/aws.

(also just getting rid of the name is effective at getting the info away from low tech surveillance like schools where someone on the route is mildly interested in seeing/blocking connections but won't bother if it's annoying to do)

There are many content blocking solutions that work at the DNS level. Encrypted DNS will bypass those.

Only if you don't control the device, in which case you're dead in the water anyways.

I am thinking about the system they use to censor the WiFi at the gym which works at the network level.

Gym… and China

Doesn't the TLS / HTTPS handshake still send the destination host name in cleartext?

https://www.ibm.com/docs/en/sdk-java-technology/8?topic=hand... doesn't look like it (at least with tls 1.3)

Capturing DNS requests is a low effort way to list all the sites you visit. Using TCP destination IPs is harder to tie to a particular website as there is shared hosting and CDN proxy-ing among other things.

Harder, but not for ~90% of websites which are uniquely tied to an IP(range).

Combining encrypted DNS and TLS 1.3 with encrypted handshakes, there's a reasonable cause for deniability which service you have accessed even if you can never hide the resolved IP address.

Even better would be to use ODoH(3), that way not even your local resolver can know who resolved what. Let's just hope TLS ECH and the rest takes off before the legislation against it.

Or anonymized DNSCrypt, which is far more deployed and reliable.

More deployed and reliable, right now. The possibility of blending in with all the rest of H/3 traffic alone is a good reason to work on (O)DoH3.

It offers privacy too. With encrypted DNS, you can only see that the source IP is making a request to the destination IP, not what type of request or what it contains.

If the source device then connects to whatever IP was in the answer, and you have that IP mapped, then you can reveal what they might be connecting to, but that requires more data and processing compared to plaintext DNS and still won't reveal the actual encrypted traffic.

With shared IPs from CDNs, hosting providers, and VPNs, it provides far more obfuscation for the average user.

There's still TLS Server Name Indication leaking the hostname.

SNI can be encrypted in an extension of TLS 1.3 called ESNI (encrypted server name indication). With both EDNS and ESNI, there's sufficient privacy coverage.

The next standard is ECH (encrypted client-hello) which secures the entire handshake: https://blog.cloudflare.com/encrypted-client-hello/

Is it still in draft state?

Yes: https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-15

They can't see that its a DNS request, it appera like any normal website connection.

Reply on news.ycombinator.com