Re: [PATCH v2 2/3] git-send-email: die on invalid smtp_encryption

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 12, 2021, 13:16 UTC
Message-ID: <87o8ejej8m.fsf@evledraar.gmail.com>
In-Reply-To: <CALQY92B6OVL.2Z59Y6W51BU4Y@taiga>

On Mon, Apr 12 2021, Drew DeVault wrote:

Show 5 quoted lines

> On Sun Apr 11, 2021 at 3:56 PM EDT, Ævar Arnfjörð Bjarmason wrote:
>> I suggest we don't compromise and just go with whatever you're OK with :)
>
> Well, if you're giving me an opportunity to not drag this out into a
> multi-phase rollout, then I'll take it :)

Just to be clear even if I was insisting on that I'm still just one guy on the ML reviewing your patch.

As a first approximation the opinion of regular contributors counts for more when the topic is some tricky interaction of code they wrote/are familiar with.

In this case we're just discussing the general interaction of security, optional switches, software versioning and how SMTP servers in the wild work.

I'd think someone who e.g. needs to regularly deal with SMTP servers in the wild would have a much better idea of those trade-offs than someone (like me) who happens to have some existing patches in git.git to git-send-email.perl.

Show 5 quoted lines

> Another option is to forbid an unknown value (which is almost certainly
> (1) wrong and (2) causing users to unexpectedly use plaintext when they
> expected encryption), file a CVE, and pitch it as a security fix - then
> we can expect a reasonably quick rollout of the change to the ecosystem
> at large.

I think anyone would agree that in retrospect "unknown is plaintext" for the "what encryption do you want" option is at best a something approaching a shotgun to your foot of a UI pattern.

But I think it falls far short of a CVE. We *do* prominently document it, a potential CVE would be if we had silent degration to plaintext (well, in a mode whose inherent workings aren't to be vulnerable to that attack, as STARTTLS is...).

FWIW since my upthread <87zgy4egtp.fsf@evledraar.gmail.com> I tried sending mail through GMail's plain-text smtp gateway as an authenticated user.

Testing with:

    nc smtp.gmail.com 25
    openssl s_client -connect smtp.gmail.com:465

It will emit a 530 if you try to AUTH in plain-text (telling you to use STARTTLS), it will also only say "AUTH" in the EHLO response to the latter.

And indeed Net::SMTP picks up on this, and doesn't even send your user/password: https://metacpan.org/release/libnet/source/lib/Net/SMTP.pm#L169

So this hypothetical degradation of the connection and sending auth over plain-text I suggested in upthread #3 seems to mostly/entirely be a non-issue as far as e.g. accidentally sending your password on some open WiFi network goes due to a local misconfiguration.

As long as the SMTP server is functional enough to say it doesn't support AUTH on plain-text you'll be OK. I'm assuming that these days with the push for "SSL everywhere" most/all big providers/MTAs have moved away from supporing plain-text auth by default.