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.
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]
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?
So I guess you couldn't get certificates for any random (MX) domain, only for those where you can obtain an inbox / user account. Still really bad, especially for things like gmail.com, but also larger enterprises. Intense.
It is unlikely that SSL.com would issue a certificate for any major mail host; it would be malpractice for them not to have some kind of exclusion list.
Issuing a Google certificate is a good way to get your whole CA killed.
Or any domain for which you can read an email sent to an inbox. I remember a few years ago an attack where the attacker would read email because a ticket would be created for incoming emails, and he could guess the next ticket ID to read it. A lot of platform that aren't email providers still allow emails in (e.g. GitHub, GitLab). This looks like a rather widely-applicable attack.
I couldn’t reproduce the attack with a pair of my own domains, so I think it might be even narrower in scope than the initial post suggests. But I suppose we will just have to wait to see what the CA says.
It's bad, but the WebPKI of the oughts featured CA certificates issued to random big enterprise IT teams that could simply issue arbitrary certificates. We've come a long ways.
> Can we trust them to release full transparent report?
Generally browser vendors take a pretty dim view of CA's not being transparent when bad things happen. Given the seriousness of this issue,i suspect being aggressively transparent is their only hope of saving their business.
I would expect them to be able to report on certificates issued based on this validation method. That's a basic CA capability and other CA incidents often include these kinds of reports.
Depending on what was logged during the validation, it might be tricky to determine if it was abuse or not. If the DNS content wasn't logged, they could pull a live record and report if the current record would support validation or not.
My guess is that use of this method should be low... If you're updating DNS to add a TXT record, you might be more likely to add a direct verification value rather than an email. But that's speculative; I'm not a CA, I've just been a customer of several... IIRC, I've validated domain control by controlling postmaster@ (or the whois address when that was public) or adding direct TXT verification records or ACME http validations.
The whole PKI concept is dead anyway. Users have been trained to bypass certificate warnings by CA store wars between browsers and OSes, MitM corporate SSL proxies a-la ZScaler / Intune, corporate self signing CAs for intranets and whatnot, blindfolded public CAs giving certs to whatever.
What? When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? What examples can you give for public CAs giving certs to "whatever"?
And remember kids: there's hundreds of CAs, they all implement validation independently, and you just need one to do one of the three validation methods wrong to make any cert you want. And there's two dozen different attacks that work aside from bugs in validation. Cert validation is swiss cheese.
But there's a fix: have the registrars confirm authority to issue certs using a public key uploaded by the domain owner. The CSR contains a request signed by the same domain owner key. The CA sends the CSR to the registrar, the registrar verifies it was signed by the same key they have, then they send back a newly signed object (that the eventual-https-end-user can later confirm was signed by the registrar, so everybody knows that every step of the way was confirmed cryptographically). This ensures a single secure authorization by the actual domain owner, verified by the registrar of the domain. All you have to change is how the CA validates, and the registrar needs to handle an extra step or two. Solves 95% of the vulnerabilities.
....but nobody's going to do that, because the fact that Web PKI is swiss cheese hasn't threatened a big enough business yet. Once money or politics is threatened, they'll fix it.
CAA account binding is basically this. Not cryptographically verified but similar idea that the CA confirms you possess a secret (account) before issuing. https://www.rfc-editor.org/rfc/rfc8657
With your solution, we end up with the same problem just one layer down. Browsers have to contain a list of 'trusted' registars, and an attacker only needs to find one buggy registrar that will incorrectly sign for a domain the attacker doesn't own.
btown|10 months ago
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.
tgsovlerkhgsel|10 months ago
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.
agwa|10 months ago
LinuxBender|10 months ago
Example using DNS validation:
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
cortesoft|10 months ago
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.
m_sahaf|10 months ago
0x0|10 months ago
tptacek|10 months ago
Issuing a Google certificate is a good way to get your whole CA killed.
remram|10 months ago
edit: I was thinking about this: https://news.ycombinator.com/item?id=41818459
cperciva|10 months ago
mukesh610|10 months ago
mcpherrinm|10 months ago
cmeacham98|10 months ago
But at least it initially appears SSL.com is taking it seriously, we'll have to see what the report says.
jenny91|10 months ago
tptacek|10 months ago
AdamJacobMuller|10 months ago
Bunch of engineers just got their easter weekend ruined. Sucks.
sneak|10 months ago
[deleted]
CrimsonRain|10 months ago
bawolff|10 months ago
Generally browser vendors take a pretty dim view of CA's not being transparent when bad things happen. Given the seriousness of this issue,i suspect being aggressively transparent is their only hope of saving their business.
toast0|10 months ago
Depending on what was logged during the validation, it might be tricky to determine if it was abuse or not. If the DNS content wasn't logged, they could pull a live record and report if the current record would support validation or not.
My guess is that use of this method should be low... If you're updating DNS to add a TXT record, you might be more likely to add a direct verification value rather than an email. But that's speculative; I'm not a CA, I've just been a customer of several... IIRC, I've validated domain control by controlling postmaster@ (or the whois address when that was public) or adding direct TXT verification records or ACME http validations.
thayne|10 months ago
thenickdude|10 months ago
https://bugzilla.mozilla.org/show_bug.cgi?id=1961406
aaomidi|10 months ago
gruez|10 months ago
Galanwe|10 months ago
peanut-walrus|10 months ago
thayne|10 months ago
voxic11|10 months ago
0xbadcafebee|10 months ago
But there's a fix: have the registrars confirm authority to issue certs using a public key uploaded by the domain owner. The CSR contains a request signed by the same domain owner key. The CA sends the CSR to the registrar, the registrar verifies it was signed by the same key they have, then they send back a newly signed object (that the eventual-https-end-user can later confirm was signed by the registrar, so everybody knows that every step of the way was confirmed cryptographically). This ensures a single secure authorization by the actual domain owner, verified by the registrar of the domain. All you have to change is how the CA validates, and the registrar needs to handle an extra step or two. Solves 95% of the vulnerabilities.
....but nobody's going to do that, because the fact that Web PKI is swiss cheese hasn't threatened a big enough business yet. Once money or politics is threatened, they'll fix it.
peanut-walrus|10 months ago
cmeacham98|10 months ago