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 

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

Reply via email to