On Tue, Mar 8, 2016 at 4:58 PM, Andrew Ayer <a...@andrewayer.name> 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. http://ocsp.buypass.no/ocsp/BPClass2CA1 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:
> https://www.agwa.name/misc/ocsp_collisions/sha1/buypass-response.ocsp
> Request text:
> https://www.agwa.name/misc/ocsp_collisions/sha1/buypass-response.txt
> Raw responder cert:
> https://www.agwa.name/misc/ocsp_collisions/sha1/buypass-response.crt
> Responder cert text:
> https://crt.sh/?q=0f4e9cdd264b025550d170806340214fe94434c9b02f697ec710fc5feafb5e38
> 2. http://ocsp.acedicom.edicomgroup.com/servidores signs responses with
> an intermediate cert which chains up to "ACEDICOM Root".  There are no
> path length constraints in the chain.
> Raw request:
> https://www.agwa.name/misc/ocsp_collisions/sha1/acedicom-response.ocsp
> Request text:
> https://www.agwa.name/misc/ocsp_collisions/sha1/acedicom-response.txt
> Raw responder cert:
> https://www.agwa.name/misc/ocsp_collisions/sha1/acedicom-response.crt
> Responder cert text:
> https://crt.sh/?q=071fa8b9e12a9632cfcb5c7e2b96ab318ccb40591713d5f914834b682d481b45
> 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:
> https://www.agwa.name/misc/ocsp_collisions/md5/poc-response.ocsp
> OCSP response text:
> https://www.agwa.name/misc/ocsp_collisions/md5/poc-response.txt
> Rogue certificate:
> https://www.agwa.name/misc/ocsp_collisions/md5/poc-rogue.crt
> Rogue certificate text:
> https://www.agwa.name/misc/ocsp_collisions/md5/poc-rogue.txt
> Root cert: https://www.agwa.name/misc/ocsp_collisions/md5/poc-root.crt
> 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?

First, thanks for the excellent write-up.  The MD5 collisions are a nice
touch :)

I would note that we could also combine these responses.  For example, we
might require that CAs retire SHA-1 for OCSP with a long-ish horizon, but
require them to use constrained OCSP certs basically ASAP.

Of course, if we could just turn off SHA-1 for OCSP, that would be
fantastic.  Do any CAs on the list know of blockers on making this switch
basically now?  E.g., are there client stacks that support SHA-2 for
verification, but not for OCSP?  (Firefox is obviously fine for both.)


> 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]
> https://www.mail-archive.com/dev-security-policy%40lists.mozilla.org/msg02994.html
> )
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
dev-security-policy mailing list

Reply via email to