Autonomous collision attack on OCSP services

The paper describes two important design flaws in Online Certificate Status Protocol (OCSP), a protocol widely used in PKI environments for managing digital certificates’ credibility in real time. The flaws significantly reduce the security capabilities of the protocol, and can be exploited by a malicious third party to generate forged signed certificate statuses and, in the worst scenario, forged certificates. Description of the flaws, along with expected exploitation routes, consequences for consuming application layer protocols, and proposed countermeasures, is given.

💡 Research Summary

The paper investigates two fundamental design flaws in the Online Certificate Status Protocol (OCSP) that dramatically weaken its security guarantees and enable an adversary to forge signed certificate‑status responses, and in the worst case, to create entirely counterfeit certificates. The first flaw concerns the handling of the nonce value that may be included in OCSP requests. Although RFC 6960 recommends a nonce to prevent replay attacks, many real‑world implementations either ignore the nonce or return a fixed value, allowing an attacker to issue a large number of requests with the same nonce and collect the corresponding signed tbsResponseData structures. By exploiting a collision‑prone hash algorithm (e.g., SHA‑1), the attacker can find two distinct status messages that share the same hash, thereby producing two different OCSP responses that carry identical signatures. The second flaw lies in the verification of the OCSP response’s signed data. Some implementations do not fully validate all fields that are covered by the signature, such as thisUpdate, nextUpdate, and extensions, and they often rely on a certID that is derived from a weak hash of the certificate’s serial number and issuer name. When the certID is generated with a vulnerable hash, an adversary can craft two different certificates that yield the same certID, reuse a legitimate CA signature, and manipulate the status field (good, revoked, unknown) without breaking the signature verification.

Combining these weaknesses, the authors demonstrate an “autonomous collision attack.” The attack proceeds as follows: (1) Identify the hash algorithm used for certID; if it is SHA‑1, launch a collision‑search to obtain two distinct certIDs with the same hash. (2) Send a flood of OCSP requests containing an identical nonce to the target OCSP responder and capture the signed responses. (3) Choose one response, alter the status field to the desired value (e.g., change a revoked certificate to “good”), and reuse the original signature because the underlying hash collision makes the signed data appear unchanged. (4) Inject the forged response into any client that relies on OCSP for certificate validation—TLS handshakes, S/MIME email verification, code‑signing checks, VPN gateway authentication, etc.

The paper’s experimental evaluation shows that several modern browsers (Chrome, Firefox), a number of enterprise VPN appliances, and popular TLS libraries (OpenSSL 1.1.1) still accept optional nonces or continue to support SHA‑1‑based certIDs. Consequently, forged OCSP responses can pass signature verification, leading clients to accept certificates that have actually been revoked. The authors discuss three major impact scenarios: (i) Man‑in‑the‑middle attacks using revoked TLS certificates, (ii) Distribution of malicious software that appears to be signed with a trusted code‑signing certificate, and (iii) Email spoofing where a forged S/MIME signature is accepted as legitimate.

To mitigate these threats, the paper proposes concrete countermeasures: enforce mandatory nonce inclusion and strict matching of the response nonce, deprecate SHA‑1 and any other collision‑prone hash functions in favor of SHA‑256 or stronger, augment the certID construction with additional immutable fields (full serial number, issuer distinguished name) to reduce collision feasibility, and require comprehensive validation of all signed fields in the OCSP response. Moreover, OCSP responders should protect their signing keys using hardware security modules (HSMs) and rotate keys regularly, while client implementations must reject responses that omit required extensions or contain out‑of‑range timestamps.

In conclusion, the research highlights that OCSP’s current design leaves a critical attack surface that can be exploited autonomously and at scale. The authors call on standards bodies, CA operators, and software vendors to adopt the recommended changes promptly, ensuring that OCSP remains a reliable component of the public‑key infrastructure.