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.
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.
They can MitM, but they can’t forge certs, they need a trusted CA to issue them, and said CA is unlikely to agree to that as that’s a sure way to get their trust removed from browsers and OSes, which would kill off their entire business.
You can’t forge a root CA, unless you’ve found a way to break RSA or trick users into installing your malicious CA. The entire chain needs to be valid for browsers to accept it, all the way up to a root that the browser trusts. It’s impossible for a CA to sign a cert but also not make it traceable to them.
If RSA gets broken, the entirety of Internet security would fall apart and the entire Internet would explode into complete chaos. Every SSH server would suddenly be broken wide open. All VPNs would be useless. Tor would be useless.
Which is why we have somewhat moved to quantum resistant crypto with elliptic curves to replace RSA, well before we actually manage to break RSA.
That’s not how certificates work. In fact, the whole point of certificates is so a man in the middle can’t do that.
When you try to visit a website at for example websiteA.com, your browser will look at the cert it receives for the website and make sure it was signed by a trusted CA, which your browser keeps a list of locally. A MiTM could make a fake CA to sign their fake websiteA.com certificate with, but your browser would obviously have no record of that fake CA and wouldn’t trust it.
In order for the attack you’re suggesting to work, the attacker would have to gain access to your host itself and plant their fake CA cert on your computer. Or somehow compromise a real trusted CA which would be… a pretty huge deal.
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.
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.
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.
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?
They can MitM, but they can’t forge certs, they need a trusted CA to issue them, and said CA is unlikely to agree to that as that’s a sure way to get their trust removed from browsers and OSes, which would kill off their entire business.
Do they though? If you’re going to forge one cert why not forge the whole chain?
You can’t forge a root CA, unless you’ve found a way to break RSA or trick users into installing your malicious CA. The entire chain needs to be valid for browsers to accept it, all the way up to a root that the browser trusts. It’s impossible for a CA to sign a cert but also not make it traceable to them.
If RSA gets broken, the entirety of Internet security would fall apart and the entire Internet would explode into complete chaos. Every SSH server would suddenly be broken wide open. All VPNs would be useless. Tor would be useless.
Which is why we have somewhat moved to quantum resistant crypto with elliptic curves to replace RSA, well before we actually manage to break RSA.
That’s not how certificates work. In fact, the whole point of certificates is so a man in the middle can’t do that.
When you try to visit a website at for example websiteA.com, your browser will look at the cert it receives for the website and make sure it was signed by a trusted CA, which your browser keeps a list of locally. A MiTM could make a fake CA to sign their fake websiteA.com certificate with, but your browser would obviously have no record of that fake CA and wouldn’t trust it.
In order for the attack you’re suggesting to work, the attacker would have to gain access to your host itself and plant their fake CA cert on your computer. Or somehow compromise a real trusted CA which would be… a pretty huge deal.
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.
a vpn is still better