[gnutls-devel] GnuTLS | OCSP Staple Index Confusion — Certificate Revocation Bypass (#1837)

[Read-only notification of GnuTLS library development activities]

Zou Dikai created an issue: https://gitlab.com/gnutls/gnutls/-/work_items/1837



## Description of problem:

When processing a stapled OCSP response during TLS certificate verification,
`check_ocsp_response()` first searches the OCSP response for the
`SingleResponse` entry that matches the peer certificate.

The matching search is performed by iterating `resp_indx`:

```c
for (resp_indx = 0;; resp_indx++) {
	ret = gnutls_ocsp_resp_check_crt(resp, resp_indx, cert);
	if (ret == 0 || ret == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE)
		break;
}
```

At that point, `resp_indx` identifies the `SingleResponse` record whose
certificate identifier matches the certificate currently being verified.

However, the subsequent status lookup does not use the matched index. Instead,
it always reads record `0`:

```c
ret = gnutls_ocsp_resp_get_single(resp, 0, NULL, NULL, NULL, NULL,
				  &cert_status, &vtime, &ntime, &rtime,
				  NULL);
```

As a result, the code can match certificate status information using one
`SingleResponse` entry, but then read revocation and freshness information from
another entry.

This affects the handshake certificate verification path. The values returned
by `gnutls_ocsp_resp_get_single()` are used to decide:

* whether the certificate is revoked
* whether the OCSP response is too old
* whether the stapled OCSP check succeeds

In other words, if a stapled OCSP response contains multiple
`SingleResponse` records and the matching certificate record is not at index
`0`, GnuTLS may apply the status of the wrong record to the certificate being
verified.

One concrete scenario is:

* `SingleResponse[0]` corresponds to a different certificate and has status `GOOD`
* `SingleResponse[1]` corresponds to the actual peer certificate and has status `REVOKED`
* the search loop finds the peer certificate at `resp_indx == 1`
* the later lookup still reads status from index `0`

This can cause the peer certificate to be evaluated using the wrong OCSP
status and timing data.

## Version of gnutls used:

3.8.12-73-g8b6731064-dirty

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)

Not distributor-specific in this report.

## How reproducible:

Steps to Reproduce:

 * Inspect `check_ocsp_response()` and confirm that it first searches all `SingleResponse` entries using `resp_indx` and `gnutls_ocsp_resp_check_crt()`.
 * Confirm that after the matching index is found, the code still calls `gnutls_ocsp_resp_get_single(resp, 0, ...)` instead of using `resp_indx`.
 * Construct a valid stapled OCSP response containing multiple `SingleResponse` entries where the peer certificate matches an entry at index `1` or later, and make the first entry carry different certificate status or validity times.

## Actual results:

The code identifies the `SingleResponse` entry matching the peer certificate,
but later reads `cert_status`, `thisUpdate`, `nextUpdate`, and
`revocationTime` from entry `0` regardless of which entry actually matched.

This can lead to the wrong revocation or freshness result being applied to the
peer certificate during the TLS handshake.

## Expected results:

Once the matching `SingleResponse` entry is identified, all subsequent OCSP
status and validity reads should use that same matched index.

That is, the code should read certificate status and timing data from
`resp_indx`, not from a hardcoded `0`.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1837
You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/4-49zbtg7kjim4b955myg6jvixx-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20260407/e6e13057/attachment-0001.html>