OCSP verification bypass with TLS session reuse

Vulnerability

In curl 8.5.0 built with OpenSSL and using TLS 1.2 only (not TLS 1.3), the SSL session ID was retained in the cache even when the Online Certificate Status Protocol (OCSP) stapling verification failed. A subsequent TLS connection to the same hostname could then reuse the cached session ID, which skipped the verify status check entirely. This affects only versions 8.5.0; versions before 8.5.0 and from 8.6.0 onward are not affected [1].

Exploitation

An attacker does not need any special network position or authentication. The attack relies on the fact that after an initial TLS 1.2 handshake with OCSP stapling that fails verification, the session ID remains cached. If a second transfer to the same hostname occurs while the cache entry is still valid (TTL-based freshness), that second transfer will reuse the cached session ID and bypass the OCSP revocation check. The attacker can be passive (observing traffic) or active (man-in-the-middle), as long as they can cause the first connection to fail verification and then trigger a second connection to the same hostname [1].

Impact

A successful exploit allows the attacker to impersonate a legitimate TLS server with a revoked certificate. The client (libcurl or curl command line) would not detect the revocation, thus the attacker gains the ability to perform man-in-the-middle attacks, intercepting or modifying data. The impact is limited to confidentiality and integrity of the affected TLS session, and no further privilege escalation is possible [1].

Mitigation

The vulnerability is fixed in curl 8.6.0, released on January 31, 2024. Users should upgrade to version 8.6.0 or later. Alternatively, apply the patch from the commit c28e9478cb2548848ec. Workarounds include not using curl built with OpenSSL, or not allowing TLS 1.2 for transfers. No KEV listing has been published as of this writing [1].