[HN Gopher] Ssl.com: DCV bypass and issue fake certificates for ...
___________________________________________________________________
Ssl.com: DCV bypass and issue fake certificates for any MX hostname
Author : xPaw
Score : 123 points
Date : 2025-04-19 18:44 UTC (4 hours ago)
(HTM) web link (bugzilla.mozilla.org)
(TXT) w3m dump (bugzilla.mozilla.org)
| cmeacham98 wrote:
| 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.
| CrimsonRain wrote:
| 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?
| thayne wrote:
| All such certs should be in transparancy logs, so I think it
| should be possible for a third party to verify.
| agwa wrote:
| 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/
| gruez wrote:
| >We will provide a preliminary report on or before 2025-04-21.
| aaomidi wrote:
| They will need to most likely do a full mass revocation at this
| point.
| toast0 wrote:
| 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.
| agwa wrote:
| 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.
| thayne wrote:
| 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.
| bawolff wrote:
| > 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.
| thayne wrote:
| Have they started revoking invalid certs?
| voxic11 wrote:
| You can see the cert was revoked here
| https://crt.sh/?id=17926238129
| progbits wrote:
| 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.
| 0x0 wrote:
| 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.
| tptacek wrote:
| 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.
| AdamJacobMuller wrote:
| 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.
| bawolff wrote:
| > 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.
| tptacek wrote:
| Less clear on that. Bugs happen. I'm not an expert on
| browser root policies.
| thayne wrote:
| From what I understand one of the factors is how often
| things like this happen, and how well they handle it when
| it does.
| agwa wrote:
| Historically, singular domain validation bugs have not
| killed CAs.
| mukesh610 wrote:
| Even then, use of a DNS CAA record should mitigate this, right?
| jsheard wrote:
| 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.
| AdamJacobMuller wrote:
| Maybe?
|
| I wouldn't assume that the bug doesn't bypass CAA checking.
|
| Very important question to answer.
| cperciva wrote:
| Or potentially one where you could subscribe to a mailing list.
| Which includes a lot of very important open source software
| projects.
| jenny91 wrote:
| Wow... this is the most serious TLS issue I've seen since
| following these things.
| AdamJacobMuller wrote:
| > We will provide a preliminary report on or before 2025-04-21.
|
| Bunch of engineers just got their easter weekend ruined. Sucks.
| sneak wrote:
| 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.)
| btown wrote:
| 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.
| agwa wrote:
| 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.
| m_sahaf wrote:
| 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?
___________________________________________________________________
(page generated 2025-04-19 23:00 UTC)