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.
Or potentially one where you could subscribe to a mailing list. Which includes a lot of very important open source software projects.
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.
Sure, gmail.com might be excluded, but its still a massive hole for a few reasons.
This would affect ANY email provider who offers public email addresses. While I agree gmail.com is probably excluded (and maybe this doesn't bypass CAA -- maybe it does) there's a whole additional surface of anyone who has an email at any big enterprise getting a certificate for their domain.
Even if I work at google.com, therefore have a google.com email, I should absolutely not be able to get a certificate for google.com just by getting an email at that company.
I doubt it's even /that hard/ to buy an email account at a big company like that in the underground world, it seems like they are valuable generally and any company with 200k employees is going to have some leaks. This massively increases the attack surface of a simple leaked email account (which might otherwise have very little or no access).
Crazy crazy oversight that has huge implications and is so easy to carry out that I would not be surprised if this was actually exploited by bad actors.
> Issuing a Google certificate is a good way to get your whole CA killed.
Surely what happened here is a good way to get your CA killed? The linked bug seems pretty bad.
Less clear on that. Bugs happen. I'm not an expert on browser root policies.
From what I understand one of the factors is how often things like this happen, and how well they handle it when it does.
Historically, singular domain validation bugs have not killed CAs.
Even then, use of a DNS CAA record should mitigate this, right?
Yeah - unless you're an actual SSL.com customer, in which case your CAA records would allow it. That's a much smaller blast radius at least.
Maybe?
I wouldn't assume that the bug doesn't bypass CAA checking.
Very important question to answer.
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.
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.
This is a ... pretty serious oversight.
But at least it initially appears SSL.com is taking it seriously, we'll have to see what the report says.
Wow... this is the most serious TLS issue I've seen since following these things.
> We will provide a preliminary report on or before 2025-04-21.
Bunch of engineers just got their easter weekend ruined. Sucks.
Maybe they should have audited the app for basic sanity during a non-holiday weekend.
(Also, Easter is only a holiday in parts of the world.)
I guess they can check logs and find how many times this has been abused already? Can we trust them to release full transparent report?
> 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.
This method may be more popular than you'd think, since it only requires the TXT record to be published once, whereas using the DNS method requires periodically updating the DNS record. Yes, that can be automated or delegated, but for a legacy/manual/dysfunctional organization, email to TXT record contact is an easy alternative to the now-banned email to WHOIS contact method that they were likely using previously.
You could at least narrow it down to certs with multiple domains, since it sounds like the email domain was added as an additional domain.
All such certs should be in transparancy logs, so I think it should be possible for a third party to verify.
Random third parties can't verify if domain validation was performed properly; only the domain owner knows. Which is why domain owners should monitor Certificate Transparency logs: https://certificate.transparency.dev/monitors/
>We will provide a preliminary report on or before 2025-04-21.
They will need to most likely do a full mass revocation at this point.
Have they started revoking invalid certs?
You can see the cert was revoked here https://crt.sh/?id=17926238129
Unclear who revoked that but I think it likely was the reporter who discovered the bug. They only needed it issued & logged as evidence, and would be good practice to revoke immediately.