From: Patrick Steinhardt <ps@pks.im>
To: Ron Nazarov <ron@noisytoot.org>
Cc: git@vger.kernel.org,
"Stanislav Malishevskiy" <stanislav.malishevskiy@gmail.com>,
"Jeff King" <peff@peff.net>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>,
"Stanislav Malishevskiy" <s.malishevskiy@auriga.com>
Subject: Re: [PATCH] config: add http.sslVerifyHost option
Date: Tue, 11 Aug 2026 14:40:31 +0200 [thread overview]
Message-ID: <ansYP7cDvtNWueIz@pks.im> (raw)
In-Reply-To: <20260807153315.9586-1-ron@noisytoot.org>
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.
So sure, using no encryption at all might be even simpler for an
eavesdropper to intercept. But in both cases they'd have to sit between
you and the server, and consequently they are very likely to have the
capability to MITM you.
There are of course going to be exception to this, like for example when
you sit on an unsecured wifi network. Other users might be able to read
your traffic there without also having the ability to modify it. But I'm
still hesitant to add this new option here as it oversells the security
benefit it offers over disabling TLS entirely.
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.
Thanks!
Patrick
next parent reply other threads:[~2026-08-11 12:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260807153315.9586-1-ron@noisytoot.org>
2026-08-11 12:40 ` Patrick Steinhardt [this message]
2026-08-11 21:19 ` [PATCH] config: add http.sslVerifyHost option brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ansYP7cDvtNWueIz@pks.im \
--to=ps@pks.im \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ron@noisytoot.org \
--cc=s.malishevskiy@auriga.com \
--cc=stanislav.malishevskiy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox