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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
