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?
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)