CVE-2024-8096: OCSP stapling bypass with GnuTLS
What the report claims
OCSP stapling bypass with GnuTLS
Compare with curl's recorded outcome
Known vulnerability
A real vulnerability: CVE-2024-8096 OCSP stapling bypass with GnuTLS
Shown for comparison after analysis. The pipeline did not see this label.
ProveIt's finding
The available evidence does not settle the report. A maintainer should investigate.
See the withdrawn model reasoning
The following reasoning failed the citation check and does not support the final finding.
- The curl GnuTLS backend code (verified present at c2e814f8d7e8) shows an inverted condition: it treats a non-zero return from gnutls_ocsp_status_request_is_checked as 'verification OK' and skips the manual status inspection that would reject revoked/unknown statuses.
- If the GnuTLS function returns non-zero whenever any stapled OCSP response exists (as the reporter states and the function name 'is_checked' could imply 'response present'), then a server sending a stapled 'unauthorized' or 'revoked' response would bypass curl's OCSP verification.
- The manual verification block (inside the if) inspects the actual status but is never reached when a response exists, and even that block appears to always return CURLE_SSL_INVALIDCERTSTATUS (suggesting additional bugs).
- External GnuTLS documentation confirms OCSP stapling is enabled by default since 3.1.2 and that gnutls_certificate_verify_peers2 automatically considers stapled responses, but does not detail which statuses it treats as errors. The reporter's claim that only 'revoked' triggers an error there is plausible and uncontradicted by provided sources.
- This is a curl logic error (misusing the GnuTLS API), not an API misuse by the user; --cert-status is a documented curl option.
What still needs checking
- Authoritative GnuTLS documentation for gnutls_ocsp_status_request_is_checked return-value semantics (the provided excerpts do not cover this function).
How this analysis ran 5 claims · 0 citations verified
Evidence check: judge quoted an external source that does not say that (https://www.gnutls.org/manual/gnutls.html)
Checked against curl master on 2024-08-19 (c2e814f8d7e8). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.
Inspect the withdrawn draft reply
This draft belongs to the withdrawn judgment. It may contain unsupported claims.
Thank you for the detailed report. The curl GnuTLS code at the revision you tested does show the logic you describe: when gnutls_ocsp_status_request_is_checked returns non-zero, curl logs 'verification OK' and skips the manual status check that would catch revoked/unknown states. If that function returns non-zero merely because a stapled response exists (regardless of its status), this is a bypass of OCSP verification. We need to confirm the exact GnuTLS API contract for that function; could you point to the GnuTLS documentation or header that defines its return values? In the meantime we are treating this as a likely valid issue in curl's GnuTLS backend.
Inspect all claims and source code 5 claims · 2 code excerpts
This model judgment was withdrawn. The claim assessments below are preserved for inspection and may be wrong.
Report claims
gnutls_ocsp_status_request_is_checked() returns non-zero when any OCSP response exists, causing the verification to treat any response as successful
Read the reasoning
The curl code structure is verifiably present and shows the inverted logic: when gnutls_ocsp_status_request_is_checked returns non-zero (which the reporter states means a response exists), curl skips manual verification and logs 'verification OK'. The function is a GnuTLS API; the provided external sources do not document its exact return-value semantics, but the curl-side logic is clear and matches the claim.
curl uses gnutls_ocsp_status_request_is_checked() to decide whether to perform OCSP stapling verification
Read the reasoning
The quoted code block is the OCSP stapling verification path in curl's GnuTLS backend, guarded by config->verifystatus (set by --cert-status).
OCSP stapling status response is configured to return "unauthorized (6)"
Read the reasoning
The test server configuration ('unauthorized (6)') is external state not visible in the provided code or deterministic checks. The claim describes the reporter's test setup, not a code property.
Connection can be established even when the certificate is revoked, bypassing OCSP verification
Read the reasoning
If the GnuTLS function returns non-zero merely because a stapled response exists (regardless of its status), curl will accept the connection even for 'revoked' or 'unauthorized' responses. The manual verification block (which inspects the actual status) is skipped entirely in that case.
curl https://ocsp4test.sytes.net:4433 --cert-status
Read the reasoning
The reproduction command depends on an external test server not under curl's control. The command syntax itself is valid for curl with GnuTLS.
What the report says about other projects
confirmed OCSP stapling is enabled by default with gnutls_init starting from GnuTLS 3.1.2
“Note that since version 3.1.2 this function enables some common TLS extensions such as session tickets and OCSP certificate status request in client side by default.” source
confirmed GnuTLS automatically considers stapled OCSP responses during certificate verification via gnutls_certificate_verify_peers2
“GnuTLS will automatically consider the stapled OCSP response during the TLS certificate verification (see gnutls_certificate_verify_peers2).” source
Read the original report (excerpt)
Source code
| 63 | #define failf Curl_failf |
| 74 | #define infof(data, ...) \ |
| 75 | do { if(Curl_trc_is_verbose(data)) \ |
| 76 | Curl_infof(data, __VA_ARGS__); } while(0) |