3 ms·

Contra GP, could you clarify how DNSSEC itself even important in this though? As far as I can tell, nearly all of my typical stack ultimately comes down to my d

by xoa 6y ago

Contra GP, could you clarify how DNSSEC itself even important in this though? As far as I can tell, nearly all of my typical stack ultimately comes down to my domain. If my registrar, account with them, or DNS is compromised that's it. Let's Encrypt will cheerfully issue all the certs hostile attackers want. They'd have the ability to get most new emails (except for PGP/custom S/MIME) and in turn most accounts as well except for those with out of band pre-shared keys required (SSH, webauthn sites, maybe SMS). "Required", because realistically with that level of access many services that claim to require 2FA could probably be socially engineered around. So I guess I'm confused how DNS records hold a public key rather than _acme-challenge would be any worse? Is it that while browsers may not be able to consistently get DNSSEC, Let's Encrypt consistently can for those that use it so it provides a weak bit of OOB workaround? I can see how that might be of some value, but not sure it's worth the trade off. I hope there's at least a concerted effort to someday secure DNS in general, thus making CAs (including LE) obsolete unless they do something beyond domain checks.

tzs 6y ago
You seem to be looking at it from the point of view of attacks against the domain owner. If someone gets control of your domain, then yes, there really isn't much difference between a system where a public key in your domain's DNS records is used by clients to tell they are talking to your sites and a system where a certificate issued by LE is used for that. As you note, once they have control of your domain they can get new certificates from LE for it. But attacks against the domain owner aren't the only kind of attacks. There are also attacks against the domain's visitors. Suppose Bob has an old router at home with out of date, buggy firmware that I know a remote exploit for that allows me to change his DNS settings. I change it so that instead of using the DNS servers it get from Bob's ISP via DHCP to resolve DNS requests from the LAN, it uses my DNS server. My DNS server points your domain to one of my sites instead of yours, where I run my nefarious fake version of your site. Under the public key on DNS server approach, it's my DNS server, so I can put a public key on it that corresponds to my keys on my fake version of your site, and everything will check out from Bob's point of view. Under the LE approach, this does not work. To get LE to issue to me a certificate for your site, I have to get LE to use a DNS server I control to resolve your domain. That's the difference. Under the current system to securely hijack your site I need to compromise your system, your DNS provider, your domain registrar, your ISP, or your hosting provider. Under the keys in DNS approach, I just need to compromise end users.
- xoa 6y ago
  Thanks for taking the time to flesh that out! I was guessing something like that might be it in a neighbor post, so automatic web CAs at this point are essentially a bit of a hack/workaround on a common inability of clients to securely verify DNS itself? And from reading it looks like there are plenty of ways to do that (from DNSSEC to DoT/DoH or even for low sophistication attacks simply hard coding a DNS server rather then depending on DHCP, though some of these themselves create other headaches), but those ways are far from universal and in some cases could have conflicts with other network middlemen? It definitely makes sense, and I completely understand how this sort of workaround can be necessary to get stuff done. But it's also too bad and I hope there can be a push towards securing DNS sooner rather then later, as it really should be the minimal source of trust in most cases. Having DNS be reliable for that with widespread support would open up a ton of additional new possibilities too, and not just for public websites.

by xoa 6y ago

tzs 6y ago

You seem to be looking at it from the point of view of attacks against the domain owner. If someone gets control of your domain, then yes, there really isn't much difference between a system where a public key in your domain's DNS records is used by clients to tell they are talking to your sites and a system where a certificate issued by LE is used for that. As you note, once they have control of your domain they can get new certificates from LE for it. But attacks against the domain owner aren't the only kind of attacks. There are also attacks against the domain's visitors. Suppose Bob has an old router at home with out of date, buggy firmware that I know a remote exploit for that allows me to change his DNS settings. I change it so that instead of using the DNS servers it get from Bob's ISP via DHCP to resolve DNS requests from the LAN, it uses my DNS server. My DNS server points your domain to one of my sites instead of yours, where I run my nefarious fake version of your site. Under the public key on DNS server approach, it's my DNS server, so I can put a public key on it that corresponds to my keys on my fake version of your site, and everything will check out from Bob's point of view. Under the LE approach, this does not work. To get LE to issue to me a certificate for your site, I have to get LE to use a DNS server I control to resolve your domain. That's the difference. Under the current system to securely hijack your site I need to compromise your system, your DNS provider, your domain registrar, your ISP, or your hosting provider. Under the keys in DNS approach, I just need to compromise end users.

xoa 6y ago
Thanks for taking the time to flesh that out! I was guessing something like that might be it in a neighbor post, so automatic web CAs at this point are essentially a bit of a hack/workaround on a common inability of clients to securely verify DNS itself? And from reading it looks like there are plenty of ways to do that (from DNSSEC to DoT/DoH or even for low sophistication attacks simply hard coding a DNS server rather then depending on DHCP, though some of these themselves create other headaches), but those ways are far from universal and in some cases could have conflicts with other network middlemen? It definitely makes sense, and I completely understand how this sort of workaround can be necessary to get stuff done. But it's also too bad and I hope there can be a push towards securing DNS sooner rather then later, as it really should be the minimal source of trust in most cases. Having DNS be reliable for that with widespread support would open up a ton of additional new possibilities too, and not just for public websites.