this post was submitted on 07 Aug 2024
59 points (95.4% liked)

Technology

59534 readers
3199 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] cmnybo@discuss.tchncs.de 28 points 3 months ago (3 children)

All you need to do is enable DoH or DoT to prevent the DNS hijacking and spying.

[–] EncryptKeeper@lemmy.world 7 points 3 months ago

Or just roll your own recursive DNS server.

[–] Bookmeat@lemmy.world 5 points 3 months ago (4 children)

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.

[–] Spotlight7573@lemmy.world 6 points 3 months ago (1 children)

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?

[–] Bookmeat@lemmy.world 3 points 3 months ago

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.

[–] umami_wasbi@lemmy.ml 3 points 3 months ago (1 children)

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.

[–] Bookmeat@lemmy.world 2 points 3 months ago (1 children)

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?

[–] Max_P@lemmy.max-p.me 6 points 3 months ago (1 children)

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.

[–] Bookmeat@lemmy.world 1 points 3 months ago (2 children)

Do they though? If you're going to forge one cert why not forge the whole chain?

[–] Max_P@lemmy.max-p.me 4 points 3 months ago (1 children)

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.

[–] Bookmeat@lemmy.world 1 points 3 months ago

Right. I forgot that browsers have the roots built in. Thanks!

[–] EncryptKeeper@lemmy.world 4 points 3 months ago* (last edited 3 months ago)

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.

[–] plz1@lemmy.world 3 points 3 months ago

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.

[–] SteveTech@programming.dev 1 points 3 months ago

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.

[–] eager_eagle@lemmy.world 3 points 3 months ago

a vpn is still better