<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<p class="details" style="font-style: italic; color: #666;">
<a href="https://gitlab.com/TheRealMichaelCatanzaro">Michael Catanzaro</a> created an issue: <a href="https://gitlab.com/gnutls/gnutls/-/issues/1332">#1332</a>
</p>
<div></div>
<h2 dir="auto">
<a id="user-content-description-of-problem" class="anchor" href="#description-of-problem" aria-hidden="true"></a>Description of problem:</h2>
<p dir="auto">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 <em>look</em> at stapled OCSP responses, at least not by default.)</p>
<p dir="auto">Downstream bug reports: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=2003363" rel="nofollow noreferrer noopener" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=2003363</a>, <a href="https://bugzilla.redhat.com/show_bug.cgi?id=2024296" rel="nofollow noreferrer noopener" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=2024296</a></p>
<h2 dir="auto">
<a id="user-content-version-of-gnutls-used" class="anchor" href="#version-of-gnutls-used" aria-hidden="true"></a>Version of gnutls used:</h2>
<p dir="auto">gnutls-3.7.2-3.fc35</p>
<h2 dir="auto">
<a id="user-content-distributor-of-gnutls-eg-ubuntu-fedora-rhel" class="anchor" href="#distributor-of-gnutls-eg-ubuntu-fedora-rhel" aria-hidden="true"></a>Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)</h2>
<p dir="auto">Fedora</p>
<h2 dir="auto">
<a id="user-content-how-reproducible" class="anchor" href="#how-reproducible" aria-hidden="true"></a>How reproducible:</h2>
<p dir="auto">Always</p>
<p dir="auto">Steps to Reproduce: <code>gnutls-cli dist.nuget.org</code> (with crypto policy set to DEFAULT)</p>
<h2 dir="auto">
<a id="user-content-actual-results" class="anchor" href="#actual-results" aria-hidden="true"></a>Actual results:</h2>
<div class="gl-relative markdown-code-block js-markdown-code">
<pre class="code highlight js-syntax-highlight language-plaintext" lang="plaintext" v-pre="true" style="border-radius: 2px; margin: 0 0 8px; padding: 8px 12px; border: 1px solid #dbdbdb;"><code><span id="LC1" class="line" lang="plaintext">Processed 155 CA certificate(s).</span>
<span id="LC2" class="line" lang="plaintext">Resolving 'dist.nuget.org:443'...</span>
<span id="LC3" class="line" lang="plaintext">Connecting to '152.199.4.184:443'...</span>
<span id="LC4" class="line" lang="plaintext">- Certificate type: X.509</span>
<span id="LC5" class="line" lang="plaintext">- Got a certificate list of 2 certificates.</span>
<span id="LC6" class="line" lang="plaintext">- Certificate[0] info:</span>
<span id="LC7" class="line" lang="plaintext"> - 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="</span>
<span id="LC8" class="line" lang="plaintext"> Public Key ID:</span>
<span id="LC9" class="line" lang="plaintext"> sha1:1c54e6eb8d5d83fff91a98314a8430b578b38924</span>
<span id="LC10" class="line" lang="plaintext"> sha256:ee0912bc6a92e170f0977829d2ddbd508e3e0e18ce224aff354f3aa1bc346d4e</span>
<span id="LC11" class="line" lang="plaintext"> Public Key PIN:</span>
<span id="LC12" class="line" lang="plaintext"> pin-sha256:7gkSvGqS4XDwl3gp0t29UI4+DhjOIkr/NU86obw0bU4=</span>
<span id="LC13" class="line" lang="plaintext"></span>
<span id="LC14" class="line" lang="plaintext">- Certificate[1] info:</span>
<span id="LC15" class="line" lang="plaintext"> - 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="</span>
<span id="LC16" class="line" lang="plaintext">- Status: The certificate is NOT trusted. The received OCSP status response is invalid. </span>
<span id="LC17" class="line" lang="plaintext">*** PKI verification of server certificate failed...</span>
<span id="LC18" class="line" lang="plaintext">*** Fatal error: Error in the certificate.</span></code></pre>
<copy-code></copy-code>
</div>
<h2 dir="auto">
<a id="user-content-expected-results" class="anchor" href="#expected-results" aria-hidden="true"></a>Expected results:</h2>
<p dir="auto">No failure... probably.</p>
<p dir="auto">Possible solutions:</p>
<ul dir="auto">
<li>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.</li>
<li>Alternative 1: Ignore the insecure OCSP response only if it indicates the certificate has <em>not</em> been revoked. If it indicates the certificate <em>has</em> 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)</li>
<li>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.</li>
<li>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).</li>
</ul>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #666;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/issues/1332">view it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.com.
If you'd like to receive fewer emails, you can
<a href="https://gitlab.com/-/sent_notifications/a55d77b84b1fbae6fc5b73d86e34f670/unsubscribe">unsubscribe</a>
from this thread or
adjust your notification settings.
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"https://gitlab.com/gnutls/gnutls/-/issues/1332"}}</script>
</p>
</div>
</body>
</html>