3 ms·

In that case, CAA doesn't help either because that record could also be faked. The answer of course is that you need DNSSEC in order for this to work, in which

by cyphar 4y ago

In that case, CAA doesn't help either because that record could also be faked. The answer of course is that you need DNSSEC in order for this to work, in which case the DNS challenge is already secure against spoofing without the need for this particular CAA extension. It doesn't hurt to have this feature, but I suspect it would primarily protect against misconfigured DNS (where there's a CNAME someone forgot to remove that points to a hosting provider an attacker can get an account on). And of course, for making the HTTP challenge more secure.

tialaramex 4y ago
> but you could restrict the challenge type before IIRC I don't think so, that's what the other change Let's Encrypt announced does: The change mentioned actually lands two CAA attributes. All the below assumes DNS integrity, either via DNSSEC or because the attacker hasn't been able to spoof your DNS records for whatever reason. The accounturi attribute lets you bind to a specific ACME account, which means an attacker has to use your Let's Encrypt account to get certificates or it won't work. That means e.g. if you have a locked down ACME issuing server that has the account credentials and is supposed to handle all your issuing, but a bug means one of your test server got rooted by bad guys -- they don't get to issue certificates because they don't have the credentials from the locked down server. The validationmethods attribute lets you specify that only some ACME methods ("challenge types") are permissible for this CA. So you can rule out methods you don't use, and thus forbid them to an adversary who might have found a way to use them. If you have DNS integrity, set CAA to letsencrypt and validationmethods to require DNS ACME verification, you only need to protect DNS records, all your application protocol stuff is unable to cause issuance. So even though your new guy's "really cool" Python web service was immediately turned into a reverse shell by a Russian teenager and is now trying to send fake Viagra spam via your company email server, it can't get itself any certificates it wasn't supposed to have, which is a small blessing.
- cyphar 4y ago
  Sorry, I edited my comment to remove that aside before you posted your reply. Ultimately this does make the HTTP challenge more secure and I mixed up which CAA bits were already supported. My point was more about how this doesn't make DNS challenges any more secure because the security of CAA ultimately depends on DNSSEC.
  - tialaramex 4y ago
    Previously you couldn't tell Let's Encrypt "Just don't use the other challenges" and you couldn't tell them "Just don't let people use their own ACME account" and so even if you only ever do DNS challenges, and you have DNS integrity, bad guys who control one of your systems can run Certbot and get themselves a certificate via the http-01 challenge. So yeah, it doesn't make the DNS challenges more secure, but in some cases it makes it possible to rule out lots of other risks outside DNS, narrowing your attack surface very considerably if you are able to do that. This is about raising the low bar, not the high bar.
    - cyphar 4y ago
      Agreed, but GP was explicitly saying that this makes DNS challenges more secure. I was simply responding to that.

by cyphar 4y ago

tialaramex 4y ago

> but you could restrict the challenge type before IIRC I don't think so, that's what the other change Let's Encrypt announced does: The change mentioned actually lands two CAA attributes. All the below assumes DNS integrity, either via DNSSEC or because the attacker hasn't been able to spoof your DNS records for whatever reason. The accounturi attribute lets you bind to a specific ACME account, which means an attacker has to use your Let's Encrypt account to get certificates or it won't work. That means e.g. if you have a locked down ACME issuing server that has the account credentials and is supposed to handle all your issuing, but a bug means one of your test server got rooted by bad guys -- they don't get to issue certificates because they don't have the credentials from the locked down server. The validationmethods attribute lets you specify that only some ACME methods ("challenge types") are permissible for this CA. So you can rule out methods you don't use, and thus forbid them to an adversary who might have found a way to use them. If you have DNS integrity, set CAA to letsencrypt and validationmethods to require DNS ACME verification, you only need to protect DNS records, all your application protocol stuff is unable to cause issuance. So even though your new guy's "really cool" Python web service was immediately turned into a reverse shell by a Russian teenager and is now trying to send fake Viagra spam via your company email server, it can't get itself any certificates it wasn't supposed to have, which is a small blessing.

cyphar 4y ago
Sorry, I edited my comment to remove that aside before you posted your reply. Ultimately this does make the HTTP challenge more secure and I mixed up which CAA bits were already supported. My point was more about how this doesn't make DNS challenges any more secure because the security of CAA ultimately depends on DNSSEC.
- tialaramex 4y ago
  Previously you couldn't tell Let's Encrypt "Just don't use the other challenges" and you couldn't tell them "Just don't let people use their own ACME account" and so even if you only ever do DNS challenges, and you have DNS integrity, bad guys who control one of your systems can run Certbot and get themselves a certificate via the http-01 challenge. So yeah, it doesn't make the DNS challenges more secure, but in some cases it makes it possible to rule out lots of other risks outside DNS, narrowing your attack surface very considerably if you are able to do that. This is about raising the low bar, not the high bar.
  - cyphar 4y ago
    Agreed, but GP was explicitly saying that this makes DNS challenges more secure. I was simply responding to that.