{"thread":{"id":"66154","subject":"Re: [PATCH] config: add http.sslVerifyHost option","startedAt":"2026-08-11T12:40:39Z","lastAt":"2026-08-12T11:57:03Z","messageCount":3,"participants":["Patrick Steinhardt","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"550284","messageId":"ansYP7cDvtNWueIz@pks.im","threadId":"66154","inReplyTo":"20260807153315.9586-1-ron@noisytoot.org","subject":"Re: [PATCH] config: add http.sslVerifyHost option","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-11T12:40:31Z","receivedAt":"2026-08-11T12:40:39Z","isPatch":true,"body":"On Fri, Aug 07, 2026 at 04:33:14PM +0100, Ron Nazarov wrote:\n> This allows for disabling host verification without completely\n> disabling TLS certificate verification.  This is useful when using TLS\n> in a decentralized way (similar to how one would use SSH), where the\n> remote endpoint has a self-signed certificate that does not\n> necessarily have a valid CN (or any CN at all), and you set\n> http.sslCAInfo to that specific certificate.  Without such an option,\n> it is impossible to use a certificate with a non-matching hostname\n> without completely disabling TLS verification, which is insecure.\n\nArguably both options are insecure, this new option just pretends to be\nsecure. If we accept arbitrary certificates for an endpoint, then it\nbecomes trivial for somebody to perform a man-in-the-middle attack\nagainst you by simply swapping out the certificate against a self-signed\none. And man-in-the-middle attacks are basically what we want to protect\nagainst with TLS.\n\nSo sure, using no encryption at all might be even simpler for an\neavesdropper to intercept. But in both cases they'd have to sit between\nyou and the server, and consequently they are very likely to have the\ncapability to MITM you.\n\nThere are of course going to be exception to this, like for example when\nyou sit on an unsecured wifi network. Other users might be able to read\nyour traffic there without also having the ability to modify it. But I'm\nstill hesitant to add this new option here as it oversells the security\nbenefit it offers over disabling TLS entirely.\n\nMaybe I'm missing something obvious. But if so, I think both the commit\nmessage and the documentation would need to be amended to document that\ngap and state that yes, this is still insecure.\n\nThanks!\n\nPatrick\n"},{"id":"550329","messageId":"anuRyMJMyAS9OMNl@fruit.crustytoothpaste.net","threadId":"66154","inReplyTo":"ansYP7cDvtNWueIz@pks.im","subject":"Re: [PATCH] config: add http.sslVerifyHost option","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-08-11T21:19:05Z","receivedAt":"2026-08-11T21:19:14Z","isPatch":true,"body":"On 2026-08-11 at 12:40:31, Patrick Steinhardt wrote:\n> On Fri, Aug 07, 2026 at 04:33:14PM +0100, Ron Nazarov wrote:\n> > This allows for disabling host verification without completely\n> > disabling TLS certificate verification.  This is useful when using TLS\n> > in a decentralized way (similar to how one would use SSH), where the\n> > remote endpoint has a self-signed certificate that does not\n> > necessarily have a valid CN (or any CN at all), and you set\n> > http.sslCAInfo to that specific certificate.  Without such an option,\n> > it is impossible to use a certificate with a non-matching hostname\n> > without completely disabling TLS verification, which is insecure.\n> \n> Arguably both options are insecure, this new option just pretends to be\n> secure. If we accept arbitrary certificates for an endpoint, then it\n> becomes trivial for somebody to perform a man-in-the-middle attack\n> against you by simply swapping out the certificate against a self-signed\n> one. And man-in-the-middle attacks are basically what we want to protect\n> against with TLS.\n\nI agree.\n\n> So sure, using no encryption at all might be even simpler for an\n> eavesdropper to intercept. But in both cases they'd have to sit between\n> you and the server, and consequently they are very likely to have the\n> capability to MITM you.\n> \n> There are of course going to be exception to this, like for example when\n> you sit on an unsecured wifi network. Other users might be able to read\n> your traffic there without also having the ability to modify it. But I'm\n> still hesitant to add this new option here as it oversells the security\n> benefit it offers over disabling TLS entirely.\n\nNo, on an unsecured Wi-Fi network one can use ARP spoofing to send all\nthe packets on the network to them before they relay them to others, so\nthey can all be modified.  I've done this in controlled environments and\nwhile the network can appear slow in some cases if you're just using a\nplain laptop, it works.\n\nSome Wi-Fi networks have some sort of isolation feature to try to\nprevent this but I've read papers that they're easy to bypass.\n\nThe assumption you absolutely must make is that anyone who can see your\npackets can also modify them.\n\n> Maybe I'm missing something obvious. But if so, I think both the commit\n> message and the documentation would need to be amended to document that\n> gap and state that yes, this is still insecure.\n\nI just don't think we should accept this option because it leads to a\nfalse sense of security and it's easy to misuse.  Moreover, getting a\nreasonable working TLS configuration is extremely easy with ACME and/or\nDANE these days, so there's really no reason to need to accommodate\nbroken self-signed certificates anymore.\n\nI'll note that technically nobody actually uses CN anymore for\ncertificate verification (and I think Go's TLS library ignores it\nentirely) and everyone uses subjectAltName, so it's possible to provide\na reasonably large number of different names for a single host.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"550395","messageId":"anxfgvcDkV6k1BLb@pks.im","threadId":"66154","inReplyTo":"7b833cd4-bad3-462a-9860-a8153d4f6b0d@noisytoot.org","subject":"Re: [PATCH] config: add http.sslVerifyHost option","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-12T11:56:50Z","receivedAt":"2026-08-12T11:57:03Z","isPatch":true,"body":"On Wed, Aug 12, 2026 at 04:31:59AM +0100, Ron Nazarov wrote:\n> On 11/08/2026 13:40, Patrick Steinhardt wrote:\n> > On Fri, Aug 07, 2026 at 04:33:14PM +0100, Ron Nazarov wrote:\n> > > This allows for disabling host verification without completely\n> > > disabling TLS certificate verification.  This is useful when using TLS\n> > > in a decentralized way (similar to how one would use SSH), where the\n> > > remote endpoint has a self-signed certificate that does not\n> > > necessarily have a valid CN (or any CN at all), and you set\n> > > http.sslCAInfo to that specific certificate.  Without such an option,\n> > > it is impossible to use a certificate with a non-matching hostname\n> > > without completely disabling TLS verification, which is insecure.\n> > \n> > Arguably both options are insecure, this new option just pretends to be\n> > secure. If we accept arbitrary certificates for an endpoint, then it\n> > becomes trivial for somebody to perform a man-in-the-middle attack\n> > against you by simply swapping out the certificate against a self-signed\n> > one. And man-in-the-middle attacks are basically what we want to protect\n> > against with TLS.\n> > \n> > [...]\n> > \n> > Maybe I'm missing something obvious. But if so, I think both the commit\n> > message and the documentation would need to be amended to document that\n> > gap and state that yes, this is still insecure.\n> > \n> \n> The intention is for this to be combined with setting sslCAInfo and/or\n> sslCAPath to the specific self-signed certificate used for the remote\n> (rather than to something like a public CA where anyone can easily get a\n> certificate signed by it).  If used on its own (with the default CA\n> certificate store) it is of course insecure.  The commit message already\n> states this (\"and you set http.sslCAInfo to that specific certificate\",\n> although perhaps it could be made more clear that if you don't do this it is\n> insecure), but the documentation currently does not.  The specific use-case\n> I am currently using this option for is a private git server accessible over\n> a public IPv6 address using a self-signed certificate which does not have a\n> valid CN (or a subjectAltName) at all.  I have something like this in my\n> .gitconfig:\n> \n> [http \"https://[2001:db8::1]/\"]\n>         sslCAInfo = /path/to/cert.pem\n>         sslVerifyHost = false\n>         sslCAPath = /dev/null\n> \n> where /path/to/cert.pem is the specific certificate served by the git\n> server, which I have verified externally to belong to the owner.  This\n> provides the same security guarantees as using SSH with the server's\n> fingerprint in my known_hosts file.\n\nOkay, that's a whole lot more reasonable then. You essentially pin the\ncertificate that you expect from the server-side, and as a result noone\ncan intercept the traffic unless they have the private key. We should\ndefinitely update the documentation then to highlight how users can\nsecurely use `sslVerifyHost` so that they're not on their own to figure\nthis out.\n\n> (Also, this is unrelated to your review, but for some reason my original\n> email containing the patch is missing from lore.kernel.org.  I don't know\n> why, since people not in the CC list are replying, it presumably must have\n> been sent to the list.)\n\nHm, curious. No idea why that is -- hopefully, v2 will land just fine.\n\nPatrick\n"}]}