4 ms·
DNSSEC struggles to justify its existence, because it's mostly useless without transport security, and for transport security we use HTTPS (TLS+WebPKI) that doe
by pornel 3y ago
DNSSEC struggles to justify its existence, because it's mostly useless without transport security, and for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC. This leaves only few scenarios where DNSSEC makes a difference.
The current Web's CAs system has obvious flaws, and periodic clown shows, but it gets just enough workarounds to maintain the status quo. DNSSEC would like to replace Web's CAs with its own (DANE), but that isn't a fundamental departure from trusting CAs, only a different arrangement of authorities.
- aleph_minus_one 3y ago> for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC There exist other application-layer protocols than HTTP.
- tialaramex 3y ago> for transport security we use HTTPS (TLS+WebPKI) that doesn't rely on DNSSEC The Web PKI relies heavily on DNS, and thus without DNSSEC it's vulnerable to spoofing. Of course people like Thomas have worked very hard to get people not to enable DNSSEC, and so a great many domains can be spoofed. Are they? Maybe†. It's hard to tell, after all there would be no sign of a problem, everything looks fine, there's no validation step because you said you didn't want one... † At a previous employer in 2019 I looked into this. Military intelligence definitely perform attacks on foreign country Internet infrastructure, but at that time they mostly seemed to rely on the fact that users don't use TLS and/or dismiss dialogs saying the certificates didn't match. The UX got better since, so I'd expect today they routinely ask a CA to issue for these unvalidatable domains once they control the packet flow.
- tptacek 3y agoDNS transaction spoofing is not, in fact, a common cause of domain hijacking; generally, when domains are stolen and have certs misissued, it's through registrar phishing. DNSSEC does not in fact solve a real problem for the WebPKI, which is why virtually none of the Internet's most sensitive WebPKI users (for instance, Google Mail) use it.
- tialaramex 3y agoI've been out of that game for more than four years now, but I'd be astonished if it's less prevalent now than it was when I left. You seem very hung up on these famous brand names, I have no doubt that works out for your career, but in practical terms those aren't targets for such attacks. Too much by-catch.
- tptacek 3y agoI have no idea what you mean here, sorry.
- tsimionescu 3y agoDisregarding the personal attack, I think they mean that DNS hijacking for TLS hijacking is in fact relatively common, but only for smaller domains.
- tptacek 3y agoIt is, but as I understand it, it's all just phishing. I haven't talked to anybody at a CA (maybe excepting Nick here?) who has told me direct cache poisoning attacks on the DNS have been a thing for domain hijacking. Like, full-on BGP4 attacks are more common (in that they actually happen). If he wants to correct me on this, he should be probably do so more clearly and less evasively? I'm being pretty specific and making claims that I think are pretty easy to falsify.
- pornel 3y agoAssuming properly issued certificate, Web PKI on the browser<=>server side is quite well protected against DNS spoofing of all kinds, and this is where DNSSEC is pointless. Users don't need to have DNSSEC-supporting resolvers, and not supporting DNSSEC only improves reliability of their browsing. CAs are deterred from misissuing by CA/B forum and CT logs. This is actually stronger than DNSSEC where browsers have no power to catch and punish malicious/incompetent CAs. Web PKI is vulnerable to DNS spoofing when issuing domain-validated certificates, and this is kinda crapshoot. It is getting "patched" with things like querying from multiple vantage points, push for RPKI to make BGP attacks harder, and certificate transparency to catch spoofing after the fact. This is a weakness, but somehow TLS hasn't collapsed yet because of that.