Re: ANN: getmail v. 5.9

Daniel Kahn Gillmor <[email protected]> Fri, 08 Feb 2019 17:41:03 -0500
Newsgroups	gmane.mail.getmail.user
Message-ID	<[email protected]>
On Fri 2019-02-08 13:27:17 -0600, Charles Cazabon wrote:
> I take it you can't upload a new package with the same version number.  I
> could bump the version number and re-release if it's a big deal.

it's not a big deal, it'll just be an inconsistency between debian and
the "current" 5.9 version.  Given that the source tarballs aren't
cryptographically verifiable anyway, people will have to compare the
contents anyway.  when they do, they'll see that there's a typographical
difference in the documentation. *shrug*

>> > cause connections to fail if the server name the user puts in their
>> > getmailrc file resolves to the correct IP address but which the server
>> > does not consider as (one of) its proper name(s).  This happens a lot with
>> > servers having many DNS aliases but which don't have valid SSL
>> > certificates installed for every corresponding name.
>> 
>> In this case, how is the client authenticating the server correctly anyway?
>> surely the certificate failure would be causing a problem for them anyway,
>> because the certificate wouldn't match the configured hostname.
>
> Take a user who's not doing certificate validation at all.  To date, getmail
> has been connecting to the server without sending SNI, but now after this
> hypothetical change, getmail sends SNI "imap.isp.example.net".
>
> And the server says "wtf, never heard of that domain, I'm
> *mail*.isp.example.net" because that's the only TLS cert and domain it's been
> configured for.  Server drops the connection with an error.

That itself smells like a bad decision on the server side (a reasonable
server that doesn't have a matching certificate should probably go ahead
and use the same certificate it would have used without any SNI).  And
the user in this story is in an unsafe configuration in the first place
because of the lack of certificate checking.

> Cue very unhappy getmail user, who had a working config, upgraded, and
> now can't retrieve his mail.

iiuc, all gmail users are currently in exactly this position if they
upgrade to OpenSSL 1.1.1 and leave TLS 1.3 enabled.  The difference with
the user above is that they are not in an unsafe configuration, because
they (think they are) verifying the certificate of the mailserver
already.

> I spent some time looking at the problem and didn't see any obvious
> way to fix Gmail's borkage without introducing problems for other
> getmail users, which is obviously not acceptable.

Breaking users of Gmail to avoid breaking unsafely-configured users of
other already-broken servers doesn't seem like a great tradeoff to me.

Additionally, the documentations' recommendation of pinning to TLS v1.2
means depriving users of the best current version of TLS (there are
meaningful cryptographic security improvements in 1.3 compared to 1.2,
such as the removal of RSA key exchange, and encryption of more of the
handshake), and they will break at some point in the future as
mailservers will eventually turn off TLS v1.2 (though i don't expect
this to happen in the near future).

I'm not a fan of gmail, and i understand antipathy toward them,
especially as they do sometimes deliberately break compatibility with
the rest of the ecosystem in other ways.  But in this case i don't think
they're doing anything particularly wrong, and sending SNI isn't
unreasonable here.

I hope you'll at least expose the option to send SNI when using TLS 1.3,
and ideally reconsider this tradeoff for the getmail defaults!

Regards,

      --dkg
signature.asc (application/pgp-signature, 227 B)