Re: CloudFlare Issuing SHA-1 SSL Certificates
On Saturday, 15 April 2017 13:59:18 UTC+1, Samuel Pinder wrote: > Quite an interesting workaround to support older > software, it's not exactly encouraging since SHA-1 collisions are now > possible. I would expect that CloudFlare operate this solution on the > condition that their customers are made aware of the risks, at the > very least. Your description of why this works, and why it isn't a concern to m.d.s.policy without some other context to make it so, is correct However, although collision itself is enough reason to consider SHA-1 flawed and reject its use for new systems entirely, functionally a collision attack poses a risk only under very tightly defined conditions, thus: A bad guy must be able to persuade the CA to sign a specific document whose content the bad guy chose in advance, so that the bad guy can then prepare a bad document with a colliding hash, whose signature would correctly be identical. For the infamous MD5 certificate attack, a CA provided a web site where robots could order (and pay for) a great number of certificates with tightly specified contents until the CA filled in exactly what was desired and signed it. This is no longer possible for a BR-compliant CA today even if the hash used is flawed. CloudFlare is not issuing certificates to a third party at all, they're either making these certificates themselves, or they have an API with the private CA which allows them to order such certificates on demand. In neither case is there a direct avenue for a bad guy to request the bogus certificate needed for a collision attack. Because cryptographic attacks only get better with time, it would be foolish for us to assume this constraint protects the wider Web PKI and thus we needn't have acted so quickly on SHA-1 already, but it would _also_ be foolish to complain of a risk from something like CloudFlare's approach here. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CloudFlare Issuing SHA-1 SSL Certificates
It looks like "CloudFlare Inc Compatibility CA-3" chains back to the "GTE CyberTrust Global Root" (see https://crt.sh/?caid=34007 ) The "GTE CyberTrust Global Root" is an old 1024 bit root that was removed from NSS two years ago (see https://bugzilla.mozilla.org/show_bug.cgi?id=1047011 ), and therefore any certificates that chain to it no longer come under more modern policies (provided that it has also been removed from other browser root stores too, but that's outside the scope here). The reason they do this is because the old root is still present in older software that is only compatible with SHA-1, and has not expired yet. This allows CloudFlare to present an SHA-1 certificate to older browsers and clients that have not been updated (and still have older versions of root stores), while presenting compliant SHA-2 certificates to modern browsers. Quite an interesting workaround to support older software, it's not exactly encouraging since SHA-1 collisions are now possible. I would expect that CloudFlare operate this solution on the condition that their customers are made aware of the risks, at the very least. While it certainly is against the BR's, there is nothing to stop people running older software, the only sanction possible is removing the root from current software, which is already done. Samuel Pinder On Sat, Apr 15, 2017 at 12:10 PM, James Burton via dev-security-policy wrote: > CloudFlare has been issuing SHA-1 SSL Certificates from CloudFlare Inc > Compatibility CA-3 which is BR violation. See: > https://crt.sh/?CN=%25&iCAID=34007 > > Thank you > > James Burton > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CloudFlare Issuing SHA-1 SSL Certificates
CloudFlare has been issuing SHA-1 SSL Certificates from CloudFlare Inc Compatibility CA-3 which is BR violation. See: https://crt.sh/?CN=%25&iCAID=34007 Thank you James Burton ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
