They can hijack the DNS answer to the DoH server, which have to happen if the system doesn’t know where to look for, and create a DoS. However, that’s how far they can go AFAIK. They can’t pretend they are the real server, nor downgrade the connection. And, it can be sidesteped by using a direct IP connection.
We use DNS just because lemmy.ml is easier to remember than 54.36.178.108 or 2001:41d0:303:486c::1. DoH can still works by direct IP connection.
Don’t most DoH resolversl settings have you enter the IP (for the actual lookup connection) along with the hostname of the DoH server (for cert validation for HTTPS)? Wouldn’t this avoid the first lookup problem because there would be a certificate mismatch if they tried to intercept it?
Well, that’s the thing. I’ve seen many instances where the DoH field is required to be a FQDN, not an IP. This always struck me as strange, but I didn’t think much on it until recently.
You’re not wrong, but you can bootstrap that request, too. It makes it more complicated, but I know NextDNS has taken steps to prevent that type of hijack with their mobile apps.
The HTTPS certs are designed to prevent MITMing, but if it’s still a worry or the domain is blocked by DNS, you can manually find the IP and add it to your hosts file instead.
All you need to do is enable DoH or DoT to prevent the DNS hijacking and spying.
Or just roll your own recursive DNS server.
With DoH, the first request to find the https DNS resolver itself is unencrypted rendering it subject to hijacking.
Correct me if I’m wrong, but that’s how I understand it.
They can hijack the DNS answer to the DoH server, which have to happen if the system doesn’t know where to look for, and create a DoS. However, that’s how far they can go AFAIK. They can’t pretend they are the real server, nor downgrade the connection. And, it can be sidesteped by using a direct IP connection.
We use DNS just because
lemmy.mlis easier to remember than54.36.178.108or2001:41d0:303:486c::1. DoH can still works by direct IP connection.Aren’t they a MITM here? Can’t they easily forge certs for the domain name of their fake resolvers since they intercept and resolve your DNS requests?
Don’t most DoH resolversl settings have you enter the IP (for the actual lookup connection) along with the hostname of the DoH server (for cert validation for HTTPS)? Wouldn’t this avoid the first lookup problem because there would be a certificate mismatch if they tried to intercept it?
Well, that’s the thing. I’ve seen many instances where the DoH field is required to be a FQDN, not an IP. This always struck me as strange, but I didn’t think much on it until recently.
You’re not wrong, but you can bootstrap that request, too. It makes it more complicated, but I know NextDNS has taken steps to prevent that type of hijack with their mobile apps.
The HTTPS certs are designed to prevent MITMing, but if it’s still a worry or the domain is blocked by DNS, you can manually find the IP and add it to your hosts file instead.
a vpn is still better