9 ms·
This is nonsense, and possibly crossing the border from ignorant nonsense to malicious nonsense. DNSSEC ensures that received DNS records are signed by an enti
by geofft 8y ago
This is nonsense, and possibly crossing the border from ignorant nonsense to malicious nonsense.
DNSSEC ensures that received DNS records are signed by an entity authorized to publish changes to the domain. It does not ensure, in any way, that this entity is publishing the right changes. It protects you against man-in-the-middle attacks, but not "hijacking" as usually envisioned. The linked article https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recen... identifies multiple cases of registrars saying that someone broke into their web interface (either by determining valid account credentials, or finding a flaw in the web interface). DNSSEC is not designed to protect against these attacks. As that article points out, some of the victims did in fact have DNSSEC set up.
As 'tptacek pointed out a few days ago, many .gov and .mil domains have DNSSEC and were nonetheless victims of DNS hijacking attacks. https://news.ycombinator.com/item?id=19180817 https://news.ycombinator.com/item?id=19180817 The US government is correctly not insisting on additional rollout of DNSSEC.
I myself have been a victim of DNS hijacking: in January 2013, someone hijacked mit.edu and (among other things) redirected the MX records to non-MIT servers. https://thetech.com/2013/01/23/hack-v132-n63 https://thetech.com/2013/01/23/hack-v132-n63 I lost email to my mit.edu address as a result, and if the attacker were interested in targeting me (or targeting MIT account holders in general) they could have triggered password resets by email, etc. They got in because they apparently knew the password for MIT's account at EDUCAUSE, domain registrar or guessed it on the first try. DNSSEC would not have prevented this. The attacker would have simply instructed EDUCAUSE to sign the records, or instructed EDUCAUSE to update the public key to one under the attacker's control.
And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took.
- agwa 8y ago> And, for bonus points, had they done so, they likely would have been able to lock out MIT of regaining control of the domain for longer than it actually took. How would DNSSEC have made it take longer?
- geofft 8y agoMaybe I'm confused about this detail of DNSSEC in which case I retract that claim - I thought it's possible to advertise a false key with a long TTL and use that to prevent people from accepting records from the true key, if they still have the false key cached. If it doesn't work that way (e.g. if all resolvers will update to new keys and accept signatures from them), great.
- agwa 8y agoAn attacker could certainly do that, but they could also advertise bogus records (e.g. the MX record in mit.edu's case) with long TTLs so I don't think DNSSEC makes the worst-case recovery time any longer.
- tptacek 8y agoThe ostensible difference is that they can advertise records that cryptographically lock out corrections, right? (I think this particular critique is mooted by the maximum TTLs mainstream caches will work on). This was Colm Maccarthaigh's scenario on Twitter last week.
- agwa 8y agoI did see Colm's Tweet last week. I'm just not sure what the attacker gains from the lockout being cryptographic, as opposed to being based on old-fashioned DNS caching. If the attacker gets an A record pointing to a bogus IP address cached in a bunch of places, that's just as bad as getting a bogus DNSSEC key cached - either way, users are locked out until the malicious records expire at their resolvers. DNSSEC makes many things worse, but I don't think this is one.
- tptacek 8y agoYeah, I feel like Paul Wouters also shot this scenario down pretty conclusively, but I'm sort of doing my best to reconstruct what colmmac was talking about and might not be doing the best job of it.
- rocqua 8y agoAs long as domain validation is the standard for getting certs, the security of the DNS system will be part of the security of DNS. At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities. DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable. In the end, the DNS system is what we use for identity management, so it should be authenticated. As the recent attacks have shown, the actual administration of the DNS servers (Registrars) also needs to be secured. That is not DNSSEC's role. But in our current system, if a registrar is compromised, the system is compromised anyway. I'd love to hear an idea that obviates the need to trust Registrars. Without such an option, I don't think 'this doesn't defend against DNS account hijacking' counts, because nothing defends against DNS account hijacking. Once someone has that account, you are fucked. HPKP is essentially the only thing that could save you, and that has (rightly) been deprecated.
- tptacek 8y agoThere is in fact very little evidence that we "need" the authentication provided by DNSSEC. Here we have an illustration of a phenomenon we've seen repeatedly: an attack for which DNSSEC has absolutely no utility, used deceptively as an argument for the necessity of DNSSEC. The same was true of claims that DNSSEC was a necessary response to BGP hijacking a few months ago. If there were actual routine attacks that DNSSEC was seriously defending against, you don't think its advocates would be sounding their trumpets about them incessantly? Occam's Razor argues emphatically that the attacks DNSSEC deals with aren't occurring. Meanwhile: if the reason we need DNS security is for certificate issuance, DNSSEC is a stupid way to get that. We can and will create a secure channel directly between CAs and registrars (one such system is RDAP, the upcoming replacement for WHOIS). We also have systems in place that have demonstrably defeated misissuance, most notably certificate transparency, which does not in any way depend on DNSSEC. CAs can and will do multi-perspective DNS lookups, which are valuable (though imperfect) even against the BGP attacks that completely bypass DNSSEC. The history of Internet network security is largely the history of higher-layer systems routing around the insecurity of DNS; an insecure DNS is practically the premise of Internet security. And throughout that entire history, going all the way back to when I was in high school in the early-mid 1990s, DNSSEC advocates have been trying to foist this boondoggle of a protocol onto us. It was annoying when it was just a bad cryptosystem that was impossible to configure. But now it's a key escrow system as well. Fuck that. DNSSEC is still failing. Let it fail all the way away.
- peterwwillis 8y agoFWIW the article states this only applies for specific MITM cases, but yeah, this is kinda bullshit. If you want to push back against this, find somebody near Kobe, Japan in the next few weeks who can go to this open session [1] and explain the problems, and provide some alternative solutions. I agree with rocqua that the Registrar needs to have a more active role in securing DNS. I think we need new standards of control between domain owners, registrars, DNS TLDs, and certificate authorities. I, as a domain owner, should be able to provide signed changes to the Registrar, and to entities further down the chain, so that just because someone gets access to my account on a service provider, they can not change anything without my private key. Delegation and revocation of other keys can also be handled for large organizations (we do that today with DNS). [1] https://meetings.icann.org/en/kobe64 https://meetings.icann.org/en/kobe64
- belorn 8y ago> I agree with rocqua that the Registrar needs to have a more active role in securing DNS. I think we need new standards of control between domain owners, registrars, DNS TLDs, and certificate authorities. There are registrars that do take a more active role in securing dns, but they usually charge a bit more. A surprising many companies and even government departments will compare two dns registrars exclusively on the price, and if one cost $10 annually and the other registrar cost $29 then they will pick the $10 version. What they might not be aware is that $9 out of the price is the registry fee, so what they are really comparing is the service that you get from $1 margin vs $20.
- deleted 8y ago[deleted]
- jakejarvis 8y agoAgreed. Requiring accredited registrars support/enforce 2FA (and preferably hardware OTPs) would be a much more effective response to this, in my opinion.
- behindmyscreen 8y agoThe whole system needs to be on DNSSEC to prevent hijacking. Just because you have a DNSSEC server doesn’t mean anything if the guy down the way can still be made to redirect traffic to a malicious site.
- fmajid 8y agoAbsolutely. It would make more sense for them to require all registrars to offer proper 2FA (i.e. SMS don’t count). This is something they have the authority to do and that would have a meaningful impact on security.
- amingilani 8y agoMaybe it won't do much for you, but for people like me whose governments actively try everything from DNS Cache poisoning to HTTP/HTML injection to censor the internet—DNSSEC would be amazing.
- deytempo 8y agoEncryption ensures ONLY one thing: that the connection is private. You could be having a private conversation with Satan
- simonsays2 8y agoSadly, on internet today, encryption does not ensure the connection is private for the client. What happens today is a client can connect to a middle server that implements TLS encryption between it and the client, but then forwards the connection unencrypted to the real server. This is an actual service people use, and the client has no way of knowing it.
- wav-part 8y agoDNSSEC+DANE replaces registrars. The entity would push signed request directly to tld.
- EGreg 8y agoWe as an industry have to stop using passwords. We have to stop using DNS. In this day and age who needs human-readable URLs? People only remember a tiny subset of most URLs anyway. Why not just make everything end-to-end encrypted and stop the stupid feudalism?
- Ajedi32 8y agoYou may have missed the part of the linked Krebs on Security article where they talked about cases where deployment of DNSSEC _did_ help: > Woodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. Those employees’ mobile devices were downloading company email via hotel wireless networks that — as a prerequisite for using the wireless service — forced their devices to use the hotel’s DNS servers, not PCH’s DNNSEC-enabled systems. > “The two people who did get popped, both were traveling and were on their iPhones, and they had to traverse through captive portals during the hijack period,” Woodcock said. “They had to switch off our name servers to use the captive portal, and during that time the mail clients on their phones checked for new email. Aside from that, DNSSEC saved us from being really, thoroughly owned.” Obviously DNSSEC won't save you if your account with your domain registrar gets compromised, but there are other situations where it _is_ effective.