Live data from Hacker News

Ssl.com: DCV bypass and issue fake certificates for any MX hostname

bugzilla.mozilla.org

41–50 of 66 posts

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#41
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.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#42
post #35

Earlier quoted context omitted.

No, because the CAA record only has to be in place at the time of issuance, rather than the whole lifetime of the certificate. Even if the semantics of CAA were changed, the challenges described in paragraph 3 of this post would apply: https://www.imperialviolet.org/2015/01/17/notdane.html

> No, because the CAA record only has to be in place at the time of issuance, rather than the whole lifetime of the certificate. could we change this? Ie. if the CAA record disappears, it would be a reason to revoke a certificate? Then 3rd parties could scan transparency logs and CAA records and flag discrepancies.

It would be possible to change, though that would be a pretty big change.

Personally I think this is another good argument for short lived certificates and reducing reliance on revocation systems.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#43
post #9

Earlier quoted context omitted.

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.

The certificate remained unrevoked in OCSP until after SSL.com acknowledged the issue, so I don’t think the reporter was the one who had it revoked.

It is also possible I was being served a stale/cached OCSP response.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#44

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.…

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.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#45
post #26

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…

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…

CAA plus DNSSEC also provides significant defense against some types of attacks on domain validation.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#46
post #6

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.

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.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#47

Earlier quoted context omitted.

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 hav…

plenty of companies have mailing lists which are listname@companydomain.com Getting on those lists is often easy. Same with support ticketing systems, etc.

Someone else on the list might figure out something was fishy when the verification email came through though.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#48
post #6

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.

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.

> Out of an abundance of caution, we have disabled domain validation method 3.2.2.4.14 that was used in the bug report for all SSL/TLS certificates while we investigate.

I think they have already addressed the bug.

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#49
post #7
post #6

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.

[dead]

Re: Ssl.com: DCV bypass and issue fake certificates for any MX hostname

#50
post #48

Earlier quoted context omitted.

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.

> Out of an abundance of caution, we have disabled domain validation method 3.2.2.4.14 that was used in the bug report for all SSL/TLS certificates while we investigate. I think they have already addressed the bug.

I tested before they acknowledged or disabled the method (I was able to use a 3.2.2.4.14 validation the “normal” way)
Post reply on HN