Good read. Thanks for an interesting post.

Since it's trivial to limit size of Nonces that are acceptable we decided to do 
that in EJBCA [1]. Returning a malformed request error in case of larges Nonce 

Of course, I have read the rest of the thread and there are probably other 
attack vectors, like serialNumber as you point out. Trivial hardening should 
still be implemented.



On Tuesday, March 8, 2016 at 11:04:08 PM UTC+1, Andrew Ayer wrote:
> As we all know, the Baseline Requirements forbid signing certificates
> with SHA-1 after January 1, 2016.  However, both the BRs and Mozilla
> policy are silent on the topic of OCSP response signatures[1].
> Theoretically, CAs could continue to sign OCSP responses with SHA-1
> indefinitely. Indeed, among the 869 distinct OCSP responder URLs
> referenced in CT logs, 351 sign responses with SHA-1 (as of
> March 5, 2016).
> ([1] The BRs forbid SHA-1 for signing "certificates to verify OCSP
> responses" after January 1, 2017, but I take that to mean the signature
> on the OCSP responder's certificate, not the OCSP responses themselves.)
> Of those 351 responders, 209 will include an attacker-controlled nonce
> of arbitrary length in the signed response (I tested with up to 1kb
> nonces). This creates a condition *extremely* favorable for a
> chosen-prefix attack. The first ~200 bytes of the hash input are
> trivially predictable (the only variable parts are the "Produced At",
> "This Update", and "Next Update" fields, which are all based on the
> current time).  This prefix is followed by the entirely
> attacker-controlled nonce.  An attacker can predict the prefix and
> stash the collision bits in the nonce to create a collision with
> another preimage, such as a certificate.
> Fortunately, the majority of those responders sign responses using a
> certificate that is restricted by ExtendedKeyUsage to OCSP signing, so
> the worst that an attacker could do is forge OCSP responses.  However,
> I found two responders that sign responses using CA:TRUE certificates
> that are trusted for server auth in NSS:
> 1. signs responses with a root
> certificate ("Buypass Class 2 CA 1") trusted for server auth in NSS.
> There is no path length constraint.
> Raw request: 
> Request text: 
> Raw responder cert: 
> Responder cert text: 
> 2. signs responses with
> an intermediate cert which chains up to "ACEDICOM Root".  There are no
> path length constraints in the chain.
> Raw request: 
> Request text: 
> Raw responder cert: 
> Responder cert text: 
> Once a chosen-prefix attack on SHA-1 becomes viable, it will be possible
> to forge a trusted CA:TRUE certificate by creating a collision with
> an OCSP response from one of these two responders.  This attack can be
> performed without a CA having to issue a SHA-1 certificate, or do
> anything that currently violates the BRs or Mozilla policy.  In fact,
> exploiting a collision against an OCSP responder is much easier than
> exploiting a collision against the certificate issuance process.  You
> can exploit it completely anonymously, you don't have to predict the
> serial number, and you have plenty of room for collision bits instead
> of having to smuggle them in the CSR's public key.  The OCSP response
> is so predictable that an attacker could predict it months in advance,
> allowing plenty of time to compute the collision.  In contrast, it took
> Stevens et al four attempts to predict even a sequential serial number
> when they forged their MD5 cert in 2008, and they spent hundreds of
> dollars on certs in the process.
> As a proof of concept, I have created an OCSP response and a CA:TRUE
> certificate which share the same MD5 signature:
> OCSP response: 
> OCSP response text: 
> Rogue certificate: 
> Rogue certificate text: 
> Root cert:
> Although this uses MD5 and my own root CA, it demonstrates that the
> OCSP format is amenable to chosen-prefix attacks, particularly with the
> attacker-controlled nonce and the very predictable prefix.  We should
> therefore be concerned about the risk of OCSP responders which use
> SHA-1 and support nonces.
> I have thought of a few ways to address the risk:
> 1. Forbid the use of SHA-1 to sign OCSP responses, effective as soon
> as possible (consider that signing certificates with SHA-1 has been
> forbidden since January 1, 2016).
> 2. Forbid OCSP nonces.  OCSP nonces are optional in practice and it's
> always risky to sign arbitrary attacker-controlled data.  Or, limit
> nonces to 32 bytes, which is long enough for an anti-replay nonce
> but probably too short to exploit a chosen-prefix attack.
> 3. Require the use of a technically-constrained OCSP responder
> certificate when doing online signing of OCSP responses.  This seems
> like a good security practice anyways, and most CAs are already doing
> this.  However, OCSP responses could still be forged.
> What do others think?
> Regards,
> Andrew
> P.S. This underscores a point which I have made several times on this
> list in the last month: with a chosen-prefix attack, the forged
> certificate need not look anything like the data which the CA signs. As
> I've demonstrated here, a CA can sign an OCSP response that can be
> turned into a certificate.  This is why various proposals like revoking
> certificates, embedding a poison extension, or blacklisting based on
> the notBefore date do absolutely nothing to address the risk of SHA-1:
> a forged certificate--the certificate that clients need to
> reject--won't have any of the markings (serial number, poison
> extension, notBefore date) that the CA placed in the "legitimate" SHA-1
> certificate. It's also why it's so important that *anything* signed by
> a CA that is trusted for server auth be in-scope for the BRs and
> Mozilla Policy, as Ryan, Rob, and I have said[2].
> ([2] 
dev-security-policy mailing list

Reply via email to