4 ms·
Ok, so deploying DNSSEC would specifically solve the threat model of an attacker who can perform a BGP hijack of IP addresses, but doesn’t want to hijack multip
by akerl_ 1y ago
Ok, so deploying DNSSEC would specifically solve the threat model of an attacker who can perform a BGP hijack of IP addresses, but doesn’t want to hijack multiple DNS server IPs because that’s more work, for a domain that has CAA records and disallows validation by ALPN.
That feels like a pretty narrow gain to justify strapping all this to all my zones and eating the operational cost and risk that if I mess it up, my site stops existing for a while
- cyberax 1y ago> but doesn’t want to hijack multiple DNS server IPs because that’s more work No. I'm saying that you can _not_ hijack a DNSSEC-enabled DNS name, even if you have a full control over the network. The DNSSEC public keys for the domain are stored in the top-level domain zone. Which in turn is protected by a signature with the key from the root zone.
- akerl_ 1y agoI don’t think you’re grokking what a BGP hijack looks like. The attacker steals traffic destined to an IP address at the routing layer. They aren’t hijacking a name, they’re hijacking traffic to the IP that name resolves to. In the case of attacking the ALPN ACME validation, they hijack the IP address of the site they want a TLS certificate for: example.org resolves to 1.2.3.4, I hijack traffic to 1.2.3.4, the DNS flow is unchanged, the verification traffic comes to me, and I get a certificate for example.org The DNS server hijack works the same way: I don’t try to change what ns1.example.org resolves to. I hijack traffic to the real IP that it resolves to and serve up responses for the site I want to hijack saying “yea, these are the records you want and don’t worry, the DS bit is set to true”. Though it’s worth remembering that both DNS and BGP attacks are basically a rounding error compared to the instances of ATO-based attacks
- cyberax 1y agoI know exactly how BGP works, I actually implemented a BGP reflector long time ago. My home has two DIA circuits and my home network is announced via BGP. > In the case of attacking the ALPN ACME validation, they hijack the IP address of the site they want a TLS certificate for: example.org resolves to 1.2.3.4, I hijack traffic to 1.2.3.4, the DNS flow is unchanged, the verification traffic comes to me, and I get a certificate for example.org As I said, a CAA record in DNS will prohibit this, instructing the ACME CA to use the DNS challenge. > I hijack traffic to the real IP that it resolves to and serve up responses for the site I want to hijack saying “yea, these are the records you want and don’t worry, the DS bit is set to true”. And then your faked DNS replies will have a wrong signature because you don't have the private key for the DNS zone. And DNSSEC-validating clients will detect this because the top-level domain will have a DNSKEY entry for the hijacked domain. You can't fake the replies from the top-level domain DNS because it in turn will have a DNSKEY entry in the root zone.