Comment by btown | Hacker News Reader

Comment by btown | Hacker News Reader

Public service announcement: CAA records exist and allow you to whitelist the CAs you trust to issue certificates for your domain.

https://letsencrypt.org/docs/caa/

You can use https://www.entrust.com/resources/tools/caa-lookup (or e.g. `dig caa paypal.com`) to see if any domain is protected.

https://isc.sans.edu/diary/26738 is a cautionary study from 2020 indicating only 3% of the Alexa top 1M had CAA records. And just now, I've seen numerous news and government sites that do not have CAA enabled... making them vulnerable to issuance bugs like this on CAs they may never have heard of, and thus making their readership/constituencies vulnerable to misinformation and fraud, especially in the context of a potential multifaceted attack against router infrastructure to perform MITM attacks at scale.

Of course, you'll want to make sure you don't accidentally disavow an important subdomain where an engineer used a different CA than your usual suspects. But looking at all historic issuers for your domain hierarchies on transparency logs using e.g. https://crt.sh/ might be a good place to start.

It's also good to monitor certificate transparency logs, but then the onus is on your security team to react if an incident occurs. Proactive controls are vital as well, and IMHO CAA avoids many of the downsides of pinning.

The CAA whitelist is still enforced by the CAs themselves, so a malicious, compromised or buggy CA could ignore it. You still have to monitor CT. CAA mostly does two things:

1. It makes sure that nobody accidentally issues a cert from another CA (giving you better control, avoiding the "an engineer used a different CA" scenario, and meaning that if you see a cert from another CA, you know it's something Very Not Good).

2. It gives you a chance that an attacker able to bypass some but not all controls on a crappy CA won't be able to use that CA to get a cert for your site (if they don't manage to somehow also bypass the CAA check).

I'm not sure whether CAA would have prevented this CA from issuing for this domain. I think it's more likely than not, but not certain, that it would have helped in this case.

Unfortunately the best solution there was for this problem was probably HPKP, which fell out of favor years ago. Would be nice to have some kind of solution for this some day; I think it would compliment CT very well.

CAA plus DNSSEC also provides significant defense against some types of attacks on domain validation.

Domain owners may find my CAA record generator <https://sslmate.com/caa/> useful, as it can automatically generate a CAA policy that covers all the certificates found in CT logs for your domain. It's not always obvious how to translate from issuer name to CAA domain (due to white labeled intermediates); my tool consults CCADB data to determine the correct CAA domain.

It may also be worth mentioning that when using CAA and also using something like LetsEncrypt one can specify which account is permitted to create and update certs and which method is approved DNS in this case. [1]

Example using DNS validation:

    0 iodef "mailto:domainowner@example.net"
    0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/xxxxxxxxxx"
    0 issuewild "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/xxxxxxxxxx"

Only useful for non-rogue CA's of course and maybe some day crt.sh will be less after-the-fact on all browsers and API clients.

[1] - https://www.rfc-editor.org/rfc/rfc8657

So CAS records are supposed to keep a CA from issuing a certificate if the CAA record exists and doesn't have that CA.

However, this is relying on the CA to properly check the record. If the CA has a bug where it isn't validating properly, they could also fail to check the CAA properly. Also, this doesn't help against a malicious or compromised CA.

I always wonder who/what checks if CAs respect CAA. I know some browsers now check the certificate transparency log, but are there any that check the CAA record against the issuer of the certificate?

Wouldn’t that be an obvious quick win?

No, because the CAA record only has to be in place at the time of issuance, rather than the whole lifetime of the certificate.

Even if the semantics of CAA were changed, the challenges described in paragraph 3 of this post would apply: https://www.imperialviolet.org/2015/01/17/notdane.html

> No, because the CAA record only has to be in place at the time of issuance, rather than the whole lifetime of the certificate.

could we change this? Ie. if the CAA record disappears, it would be a reason to revoke a certificate?

Then 3rd parties could scan transparency logs and CAA records and flag discrepancies.

It would be possible to change, though that would be a pretty big change.

Personally I think this is another good argument for short lived certificates and reducing reliance on revocation systems.

Reply on news.ycombinator.com