[gnutls-devel] GnuTLS | Insecure OCSP signature should cause OCSP response to be ignored, not fail certificate verification (#1332)

[Read-only notification of GnuTLS library development activities]

Michael Catanzaro created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1332



## Description of problem:

Currently if a server provides a stapled OCSP response signed with an insecure signature (e.g. SHA-1), certificate verification will fail due to use of an insecure algorithm. Normally it makes sense to fail when we see something insecure, but in this case, the connection would have succeeded had the server not provided any OCSP response at all! It feels like we are punishing the user for the server's failed attempt to improve security by stapling an OCSP response. Moreover, all other TLS clients handle this properly (to my knowledge). Only GnuTLS on Fedora/RHEL fails. (Most non-GnuTLS clients do not even _look_ at stapled OCSP responses, at least not by default.)

Downstream bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=2003363, https://bugzilla.redhat.com/show_bug.cgi?id=2024296

## Version of gnutls used:

gnutls-3.7.2-3.fc35


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

Fedora

## How reproducible:

Always

Steps to Reproduce: `gnutls-cli dist.nuget.org` (with crypto policy set to DEFAULT)

## Actual results:

```
Processed 155 CA certificate(s).
Resolving 'dist.nuget.org:443'...
Connecting to '152.199.4.184:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=*.nuget.org,O=Microsoft Corporation,L=Redmond,ST=WA,C=US', issuer `CN=Microsoft Azure TLS Issuing CA 05,O=Microsoft Corporation,C=US', serial 0x330017f392df3169646870385900000017f392, RSA key 2048 bits, signed using RSA-SHA384, activated `2021-08-03 22:49:43 UTC', expires `2022-07-29 22:49:43 UTC', pin-sha256="7gkSvGqS4XDwl3gp0t29UI4+DhjOIkr/NU86obw0bU4="
	Public Key ID:
		sha1:1c54e6eb8d5d83fff91a98314a8430b578b38924
		sha256:ee0912bc6a92e170f0977829d2ddbd508e3e0e18ce224aff354f3aa1bc346d4e
	Public Key PIN:
		pin-sha256:7gkSvGqS4XDwl3gp0t29UI4+DhjOIkr/NU86obw0bU4=

- Certificate[1] info:
 - subject `CN=Microsoft Azure TLS Issuing CA 05,O=Microsoft Corporation,C=US', issuer `CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0d7bede97d8209967a52631b8bdd18bd, RSA key 4096 bits, signed using RSA-SHA384, activated `2020-07-29 12:30:00 UTC', expires `2024-06-27 23:59:59 UTC', pin-sha256="4i4h0jN9NROr1xKJI+TQ1Q/ZIfUjPMXtmWUsDR3Pjiw="
- Status: The certificate is NOT trusted. The received OCSP status response is invalid. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
```


## Expected results:

No failure... probably.


Possible solutions:

 * Simple solution: Ignore the insecure OCSP response. This would treat the insecure OCSP response as equivalent to no OCSP response, so the certificate would be trusted, which seems better than failing the certificate verification.
 * Alternative 1: Ignore the insecure OCSP response only if it indicates the certificate has _not_ been revoked. If it indicates the certificate _has_ been revoked, accept the response anyway and distrust the certificate. After all, it would be really weird for a security policy intended to improve security ("SHA-1 is insecure, do not use SHA-1") to result in lower security (trusting a certificate that we know to be revoked because we didn't like the OCSP response)
 * Alternative 2: fail the certificate verification, but do so using a new error code, so clients can choose to ignore this condition if desired. This seems less desirable, because it would require modifications in all clients that wish to be web-compatible.
 * Alternative 3: add a switch to choose the desired behavior, in case we want to be stricter in RHEL (which might want to adopt alternative 2) than in Fedora (which would really prefer alternative 1 IMO).

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1332
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20220302/14098f5b/attachment.html>