Hi Andrew

Thank you for making us aware of this issue with our OCSP responder.

We did make a major change in our CAs some years ago where we among other 
things established a new OCSP responder for all Buypass CAs used for 
SSL/TLS-certificates (including Buypass Class 2 CA 1). However, the original 
OCSP responder for Buypass Class 2 CA 1 is still active, even though it is not 
referenced for use in SSL/TLS-certificates today.

We will do some investigation in order to identify any potentially problematic 
consequences of disabling this OCSP responder before we can decide to do so. 
However, as a short term measure we have reconfigured the OCSP responder to use 
SHA256 instead of SHA-1. 

-----Original Message-----
From: dev-security-policy 
 On Behalf Of Andrew Ayer
Sent: 8. mars 2016 22:58
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: OCSP Responders Are An Attack Vector For SHA-1 Collisions

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: 
Request text: 
Raw responder cert: 
Responder cert text: 

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: 
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 c
 erts 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: 
Rogue certificate: https://www.agwa.name/misc/ocsp_collisions/md5/poc-rogue.crt
Rogue certificate text: 
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?


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].

dev-security-policy mailing list
dev-security-policy mailing list

Reply via email to