Re: [PATCH] config: add http.sslVerifyHost option

On Wed, Aug 12, 2026 at 04:31:59AM +0100, Ron Nazarov wrote:
> On 11/08/2026 13:40, Patrick Steinhardt wrote:
> > On Fri, Aug 07, 2026 at 04:33:14PM +0100, Ron Nazarov wrote:
> > > This allows for disabling host verification without completely
> > > disabling TLS certificate verification.  This is useful when using TLS
> > > in a decentralized way (similar to how one would use SSH), where the
> > > remote endpoint has a self-signed certificate that does not
> > > necessarily have a valid CN (or any CN at all), and you set
> > > http.sslCAInfo to that specific certificate.  Without such an option,
> > > it is impossible to use a certificate with a non-matching hostname
> > > without completely disabling TLS verification, which is insecure.
> > 
> > Arguably both options are insecure, this new option just pretends to be
> > secure. If we accept arbitrary certificates for an endpoint, then it
> > becomes trivial for somebody to perform a man-in-the-middle attack
> > against you by simply swapping out the certificate against a self-signed
> > one. And man-in-the-middle attacks are basically what we want to protect
> > against with TLS.
> > 
> > [...]
> > 
> > Maybe I'm missing something obvious. But if so, I think both the commit
> > message and the documentation would need to be amended to document that
> > gap and state that yes, this is still insecure.
> > 
> 
> The intention is for this to be combined with setting sslCAInfo and/or
> sslCAPath to the specific self-signed certificate used for the remote
> (rather than to something like a public CA where anyone can easily get a
> certificate signed by it).  If used on its own (with the default CA
> certificate store) it is of course insecure.  The commit message already
> states this ("and you set http.sslCAInfo to that specific certificate",
> although perhaps it could be made more clear that if you don't do this it is
> insecure), but the documentation currently does not.  The specific use-case
> I am currently using this option for is a private git server accessible over
> a public IPv6 address using a self-signed certificate which does not have a
> valid CN (or a subjectAltName) at all.  I have something like this in my
> .gitconfig:
> 
> [http "https://[2001:db8::1]/"]
>         sslCAInfo = /path/to/cert.pem
>         sslVerifyHost = false
>         sslCAPath = /dev/null
> 
> where /path/to/cert.pem is the specific certificate served by the git
> server, which I have verified externally to belong to the owner.  This
> provides the same security guarantees as using SSH with the server's
> fingerprint in my known_hosts file.

Okay, that's a whole lot more reasonable then. You essentially pin the
certificate that you expect from the server-side, and as a result noone
can intercept the traffic unless they have the private key. We should
definitely update the documentation then to highlight how users can
securely use `sslVerifyHost` so that they're not on their own to figure
this out.

> (Also, this is unrelated to your review, but for some reason my original
> email containing the patch is missing from lore.kernel.org.  I don't know
> why, since people not in the CC list are replying, it presumably must have
> been sent to the list.)

Hm, curious. No idea why that is -- hopefully, v2 will land just fine.

Patrick