5 ms·

No, it doesn't work like that. Certificate Transparency Log makes this almost impossible to do this undetected. In addition to this you have CAA records which

No, it doesn't work like that. Certificate Transparency Log makes this almost impossible to do this undetected. In addition to this you have CAA records which quickly would make it evident for the entire world that said certificate is fraudulent and that the signing CA isn't to be trusted anymore.

schoen 5y ago
I used to think that CAA records would be checked at both issuance time and certificate acceptance time, but someone on Hacker News (probably tialaramex) corrected me: the CAA RFC specifically says that it should only be checked at issuance time and that it's not valid to check it at acceptance time. As a result, there's no browser that checks CAA or uses it to warn about possibly-misissued certificates. Furthermore, if you reported a certificate to a CA or browser based on an apparent conflict with CAA issuance policies, you would probably get the reply that that only applies at issuance time. And someone in possession of a misissued certificate that was being used for an attack might try to take care not to present it to researchers doing Internet-wide scans (at least to avoid attracting even more attention). But nowadays it would have to be logged in CT logs, so researchers could find it if they had some reason to suspect it -- or, hopefully, the legitimate site operator could find it. Conclusion: CAA (by design) typically only protects you from accidents; it doesn't really help to prevent or detect deliberate misissuance. But CT does.
- vegardx 5y ago
  Makes complete sense, and like you said, this information is key for security researchers who routinely trawls CT logs looking for discrepancy. And failing on CAA shortly after issuance is quite a huge red flag. If the scenario of rogue national state managed CAs was an issue we'd have pretty good evidence of it by now. Another, somewhat unrelated, benefit of CAA records is that it allows you to keep tighter control over who and what inside your organization is allowed to issue/control certificates.
- tialaramex 5y ago
  Yes, it probably was me. CAA assumes the Certificate Authorities are honest which I believe on the whole is a reasonable assumption - but it doesn't only protect you against accidents. Malevolence from third parties might be blocked by CAA too. For example, suppose you conclude the some of the 3.2.2.4 Blessed Methods are unacceptably vulnerable to impersonation of your organisation. You identify that a particular CA specifies in their CPS that they never use any of these methods, you can use CAA to tell every other CA not to issue. As a result, these methods cannot be used to successfully obtain certificates that shouldn't exist. If an adversary tries to use another CA your CAA record tips off that CA that there's a problem, and if they try on your preferred CA then the vulnerable methods aren't offered. I believe there is still work in progress to try to hook CAA together with ACME so that it would be practical to express "Only Let's Encrypt may issue, and only using dns-01" which rules out a lot of otherwise practical attacks for a resourceful adversary, but I don't track the status of that work.

schoen 5y ago

I used to think that CAA records would be checked at both issuance time and certificate acceptance time, but someone on Hacker News (probably tialaramex) corrected me: the CAA RFC specifically says that it should only be checked at issuance time and that it's not valid to check it at acceptance time. As a result, there's no browser that checks CAA or uses it to warn about possibly-misissued certificates. Furthermore, if you reported a certificate to a CA or browser based on an apparent conflict with CAA issuance policies, you would probably get the reply that that only applies at issuance time. And someone in possession of a misissued certificate that was being used for an attack might try to take care not to present it to researchers doing Internet-wide scans (at least to avoid attracting even more attention). But nowadays it would have to be logged in CT logs, so researchers could find it if they had some reason to suspect it -- or, hopefully, the legitimate site operator could find it. Conclusion: CAA (by design) typically only protects you from accidents; it doesn't really help to prevent or detect deliberate misissuance. But CT does.

vegardx 5y ago
Makes complete sense, and like you said, this information is key for security researchers who routinely trawls CT logs looking for discrepancy. And failing on CAA shortly after issuance is quite a huge red flag. If the scenario of rogue national state managed CAs was an issue we'd have pretty good evidence of it by now. Another, somewhat unrelated, benefit of CAA records is that it allows you to keep tighter control over who and what inside your organization is allowed to issue/control certificates.
tialaramex 5y ago
Yes, it probably was me. CAA assumes the Certificate Authorities are honest which I believe on the whole is a reasonable assumption - but it doesn't only protect you against accidents. Malevolence from third parties might be blocked by CAA too. For example, suppose you conclude the some of the 3.2.2.4 Blessed Methods are unacceptably vulnerable to impersonation of your organisation. You identify that a particular CA specifies in their CPS that they never use any of these methods, you can use CAA to tell every other CA not to issue. As a result, these methods cannot be used to successfully obtain certificates that shouldn't exist. If an adversary tries to use another CA your CAA record tips off that CA that there's a problem, and if they try on your preferred CA then the vulnerable methods aren't offered. I believe there is still work in progress to try to hook CAA together with ACME so that it would be practical to express "Only Let's Encrypt may issue, and only using dns-01" which rules out a lot of otherwise practical attacks for a resourceful adversary, but I don't track the status of that work.