21–30 of 66 posts
Earlier quoted context omitted.
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.
> 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.
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?
All such certs should be in transparancy logs, so I think it should be possible for a third party to verify.
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?
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…
Have they started revoking invalid certs?
You can see the cert was revoked here https://crt.sh/?id=17926238129
> We will provide a preliminary report on or before 2025-04-21. Bunch of engineers just got their easter weekend ruined. Sucks.
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.
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?
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…
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 j…
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?
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.
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.