Re: [PATCH v2] http: add http.sslVerifyStatus to check stapled OCSP responses

From: Grayson Gordon <graysongordon1@gmail.com>
Date: Aug 12, 2026, 15:53 UTC
Message-ID: <CALgUfNhoSdp191e=r6593GQHAC6DQsfh=g7hB+SwnRRGEzAGDw@mail.gmail.com>
In-Reply-To: <anwR3Inkf-9nLmYm@pks.im>

Patrick,

Thank you for reviewing my submission!

I understand the "nit" you're describing: software can't exactly be called the same thing if it is built against different libraries, which in turn creates an opportunity for different behaviors. I agree with your follow-up that we should aim to maintain consistency despite those library choices. The benefits of the Principle of Least Astonishment are well established, and I would argue that users reasonably expect Git to behave consistently regardless of the underlying TLS library.

I can provide additional context to motivate this change. Like you, I currently work for GitLab, but as part of the Professional Services organization, which works directly with customers deploying the software in their environments for production use. I am supporting a government customer whose servers use OCSP stapling. There are many such government and government-adjacent customers that utilize certificates issued by US Department of Defense PKI CAs, which have published policies that explicitly outline support for OCSP: https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/Unclass-DoD_X.509_Certificate_Policy_v10.7_Jun_3_21.pdf. Many DoD PKI CAs serve certificates with stapled OCSP responses today and can reasonably be expected to continue to do so until there is a DoD-wide policy change.

A related bug in GnuTLS has affected my customer in their current production environment, preventing them from being able to push-mirror to repositories on remotes whose servers use OCSP stapling. The push-mirror failure is what prompted my initial investigation into this issue.

Original GnuTLS issue: https://gitlab.com/gnutls/gnutls/-/work_items/1372, resolved in GnuTLS 3.8.8.

GitLab issue on the Cloud Native GitLab build that resolves this behavior in GitLab's default Helm chart base image: https://gitlab.com/gitlab-org/build/CNG/-/work_items/2374#note_3653072099

GitLab ships its Helm charts with two primary "flavors": one based on Debian and the other on UBI. On Debian, the default SSL backend is GnuTLS, and the aforementioned issues resolve the problem. On UBI, the default backend is OpenSSL, and this issue surfaces. For my government customers who need FIPS, switching to the UBI-based image is the long-term path forward: https://gitlab.com/graysongordon-gl/gitaly-tls-experiments/-/blob/main/docs/FIPS-AND-THE-TLS-BACKEND.md?ref_type=heads.

To be more explicit, OpenSSL-linked Git binaries are the default case for many government customers, and those customers frequently interface with Git servers that use this type of certificate revocation mechanism.

In summary, there are many instances of Git servers serving a large base of developers working on government-related software that are impacted by this issue and need this functionality. These users have experienced the pain and confusion of this behavior being broken firsthand in downstream applications and have brought the issue to me. These customers care that their Git clients respect certificate revocation when it occurs, whether from their development machines or through service-to-service communications over Git on platforms like GitLab. They interface with these kinds of certificates frequently and will continue to do so, which warrants the inclusion of this flag. The benefit they would receive is correct validation of a remote's certificate.

As it stands today, users leveraging OpenSSL-linked Git binaries can receive a response indicating that the certificate is valid even when the stapled OCSP response indicates that the certificate has been revoked. I think there is a reasonable case that this could qualify as a low-to-medium severity CVE.

The threat model is:

An attacker steals the private key of a Git server whose certificate is accompanied by an OCSP-stapled response. The breach is detected, and the certificate authority revokes the certificate. Despite the revocation, Git clients continue to accept the certificate and push/pull code from a malicious Git server impersonating the legitimate server. A malicious actor could leverage this to facilitate the exfiltration of an organization's Git data.

Similar CVEs against libcurl include: https://curl.se/mail/lib-2026-04/0036.html, https://curl.se/docs/CVE-2024-0853.html

In addition, the attacker would need a mechanism for intercepting or redirecting the victim's connection to the Git server, hence this not being a higher-severity issue. However, I think that in the context of DoD systems, this is sufficiently dangerous to warrant remediation, and this patch provides that capability.

On the GitLab side, we already have mechanisms for per-remote configuration values to be passed, and integrating this would not be a monumental lift.

Thank you, Grayson

On Wed, Aug 12, 2026 at 2:25 AM Patrick Steinhardt <ps@pks.im> wrote:

Show 72 quoted lines

>
> On Tue, Aug 11, 2026 at 04:44:07PM -0400, graysongordon-gl wrote:
> > From: Grayson Gordon <graysongordon1@gmail.com>
> >
> > git asks libcurl to verify the peer certificate and the hostname, but it
> > never sets CURLOPT_SSL_VERIFYSTATUS, so the "Certificate Status Request"
> > TLS extension is never requested and any stapled OCSP response the server
> > does send is ignored.
> >
> > On an OpenSSL-linked build this is silent. OpenSSL hands the stapled
> > response to the application and takes no view on it:
> > SSL_CTX_set_tlsext_status_cb(3) says the callback "should determine
> > whether the returned OCSP response(s) are acceptable or not", and libcurl
> > only installs that callback when CURLOPT_SSL_VERIFYSTATUS is set. So git
> > will fetch from a server whose own staple says its certificate has been
> > revoked.
> >
> > A GnuTLS-linked build behaves differently, and the difference does not
> > come from curl. GnuTLS consults a stapled response inside
> > gnutls_certificate_verify_peers(), so the failure surfaces through the
> > verifypeer branch of curl's GnuTLS backend (lib/vtls/gtls.c) whether or
> > not CURLOPT_SSL_VERIFYSTATUS was ever set. The same git, against the same
>
> Nit: this is arguably not the same git, as it links against different
> libraries. It is not exactly unexpected that using different
> dependencies may cause different behaviour, even though we should of
> course try to minimize the differences.
>
> > server, therefore enforces revocation or not depending only on how its
> > libcurl was built. That difference is documented here rather than papered
> > over: this option turns the check on where the backend needs asking, and
> > setting it to false does not turn the check off on GnuTLS.
> >
> > Add an http.sslVerifyStatus boolean that sets CURLOPT_SSL_VERIFYSTATUS.
> > Because http_options() is the collect_fn of a urlmatch config, the
> > per-URL form works with no further changes:
> >
> >     git config http.https://example.com/.sslVerifyStatus true
> >
> > It defaults to false, and has to. The option is fail-closed: libcurl fails
> > verification when the server staples nothing at all, so turning this on
> > globally would break every remote that does not staple.
> >
> > Leaving the default to libcurl is not an option either. The same
> > complaint was raised there in https://github.com/curl/curl/issues/15483
> > and closed as intentional ("Marked as enhancement since this was done on
> > purpose"), with the observation that stapling is expected to see less use
> > as Let's Encrypt drops OCSP support. If the check is to be reachable at
> > all, the lever has to come from the application.
>
> Okay. One could make the argument that we shouldn't add support for OCSP
> either if it's being phased out now. But I assume there's still going to
> be enough servers out there that do use it.
>
> The big question to me is why we want to have this change in the first
> place. It doesn't help to address the behaviour difference between
> GnuTLS and OpenSSL: if set to "false" OpenSSL would continue to ignore
> OCSP, whereas GnuTLS would still honor it. If set to "true", OpenSSL
> would fail closed, whereas GnuTLS would still behave the same as before.
> So nothing really changes here, unless I misunderstand something.
>
> We don't really gain security, either, because the setting is disabled
> by default and can only be enabled host-by-host. I doubt anybody out
> there is really going to do that though, and consequently we haven't
> really made the world a more secure place :/
>
> So is there any specific use case that you're after? Who exactly is this
> new feature for?
>
> Thanks!
>
> Patrick