So, I read some articles on DOH and looks like the whole thing is a myth and doesn’t really help in enhancing user privacy and security. Even if the DNS requests are encrypted, the ISP will still be able to track you.
What are your thoughts?
Hi!
Using DNS over https (DOH) prevents your Internet Service Provider (ISP) from monitoring your traffic. However, DOH doesn’t hide your IP address which is the elephant in the room since only with that piece of data is possible to determine what are the websites visited by the user. Moreover, Server Name Indication (SNI) - an extension to Transport Layer Security (TLS) - leaks the hostname that the client is attemping to connect to.
So, if you want to hide the websites you visit, a good idea would be using a VPN or Tor. However, even VPN has his own problems
If you want to learn more, i will link you a couple of article written by madaidan plus some other sources.
- DNS problems
https://madaidans-insecurities.github.io/encrypted-dns.html https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/
- VPN problems
This is due to SNI if I remember correctly.
For context: SNI is a header in the TLS session which indicates which service you intend to communicate with on the other side. Why? Usually, you reach a reverse proxy and firewall) terminating the TLS connection on the publicly-routable IP of the remote server, and from there follow a route on a local network unencrypted.
However, in some situations it’s not very practical for your architecture, and you have a single public IP for many services/servers each with their own domain names and TLS keys, so you need to be able to route the TLS traffic to its intended destination. That’s why your browser sends a “SNI” header indicating it would like to reach “foobar.com”, and that header is not encrypted because it’s meaningful before the TLS connection is terminated.
Lately, there’s been a push for encrypted SNI. The idea is by establishing an encrypted session with the reverse proxy specifically for SNI-based proxying, that header can be concealed to its intended destination without being readable by any person-in-the-middle on the network.
Currently, DoH does very little from a privacy perspective in hiding the sites you visit from your ISP. Even if it hides the DSN query, the domain you connect to can still be read in plain text by your ISP from the SNI field of the TLS handshake.
Until Encrypted Client Hello is standardized and used widly, DoH will be rather pointless. However once both are implemented and enabled, your ISP should have more difficulty knowing which sites you connect to. The ISP will only have access to the IP of the site, and that doesn’t mean much when it’s the IP of a Cloudflare proxy for instance, which are used by millions of websites.
Some services used Domain Fronting to achieve similar privacy and avoid censoriship, but this is mostly just abusing a bug in the implementation of large cloud providers, and is now banned in most cloud providers.
doesn’t really help in enhancing user privacy and security.
It does help with security, since you can trust the query wasn’t tampered with.
If you’re looking for an anti-tampering mechanism, DNSSEC signatures is what you’re looking for. DNS Over HTTPS establishes a “reasonably-secure” [1] connection to the DNS resolver. Not accounting for [1], that resolver (Cloudflare or other) can still lie to you consciously, or propagate unconsciously a malicious answer it received, because recursive resolution (i believe) still has no standard for secure transport: DNS over TLS is slowly getting traction, but it’s far from deployed on every primary nameserver.
[1] HTTPS is somewhat-secure because it’s an effective defense against script kiddies and malicious ISPs. However, it’s a very weak threat model where dozens of actors (the Certificate Authorities) can impersonate (almost) any server. And they do just that. It’s crazy how many CAs over the years have been caught misbehaving, often with little consequence except in the most egregious cases where Mozilla/Google pushed for their revocation as part of BrowserCA.
If you’re looking for an anti-tampering mechanism, DNSSEC signatures is what you’re looking for.
Not really. DNSSEC validation is done by the resolver, not the end device. So a malicious resolver (or a spoofed response) could still lie to you.
DoH does prevent the possibility of spoofing the response coming from the resolver, but you still have to trust the resolver not to lie to you.
DNSSEC validation is done by the resolver, not the end device.
It depends on your actual setup. If you operate your own network, DNSSEC validation will probably happen on your local DNS resolver (usually on your router). But also your forwarding/stub resolvers running on your own machine could (should?!) validate DNSSEC signatures… i’m not sure what the default is on most systems, though.
i’m not sure what the default is on most systems, though
AFAIK this kind of setup is only used by people that use pi-hole for example. In most cases I don’t think that ISP routers have a recursive DNS resolver, I think most of the time the recursion is done by an ISP resolver outside of your LAN.
