Re: [Fetchmail-devel] fetchmail-6.4.0.rc2 final candidate - please translate to your language, and test!

[Matthias A. <mat...@gm...>]

Am 20.08.19 um 08:37 schrieb grarpamp:
> A note that these days no one should be configuring
> anything less than TLS 1.2, or building against less
> than openssl 1.1.1, unless they have no other choice.
> All lesser are either broken and insecure, or out of support.
> Continuing using them can put you at risk,
> and hamper development.

(Deliberately chose the -devel list...)

Jumping the gun while the big graphics MUAs such as Microsoft's,
Mozilla's and the big ones on Android and iOS were still permitting
older TLS levels, meaning that they don't exert major pressure on ISPs,
is no good. If users need to jump hoops because their provider only goes
up to TLS 1.1 while fetchmail demands TLS 1.2 they'll use whatever
insecure crap comes their way "but works".

See, the important first step is moving people away from fetchmail <=
6.3.26 to a version 6.4.0 that has a halfway decent TLS support - so
that a sufficiently underconfigured fetchmail 6.4.0 will OOTB

* pull in SSL at all,

* permit compilation against a recent and pure (no compatibility cruft
and possibly SSLv3 disabled) OpenSSL version,

* so that it can talk TLS v1.2 and possibly v1.3 in the first place,

* and getting *any* kind of reasonable server identity checking (X.509)
into place.

It isn't as strict as recent RFCs (numbers below to keep you excited)
recommend, but I can't destroy the user's forward path if their ISPs are
lazy.

> A release such as 6.4.0 is a good time to try
> updated software against your server. If your server
> does not support at least TLS 1.2, ask your provider
> to update per any easily found RFC or other deprecation
> notice, rationale, or howto on the net.

For users, that is true. The standing IETF RFC-based recommendation
(RFCs 7817, 8314 to mention just two starting points) however is TLS 1.1
or newer, or 1.3 if you use client certificates and a bit of user privacy.

Of course I'd endorse users lobbying their ISP if the latters' servers
aren't TLS-1.3-enabled yet, but if I want to really tighten up default
security I want to make the options users need to use in order to
relax/override security checks as scary, cumbersome to type and talking
as possible. Options such as --connect-insecurely-and-waive-cert-check
or something.

That is, however, a major user interface change that conventionally goes
only with a version bump to 7.0.0 - such that everyone halfway
acquainted with software *EXPECTS* something hard is flying right into
their faces with respect to compatibility.

I have already changed the --sslproto semantics and --sslcertck defaults
for 6.4.0 which is pretty hard for a minor release.

And the world really needs to upgrade fetchmail-on-Cygwin! 6.3.18,
6.3.21 or 6.3.22 have critical and security relevant bugs. I'll notify
cygwin@.

I'll also be pulling the plug on a lot of old systems soonish, but not
in 6.4.0. We really need that "no excuses" way forward, and that means I
can't give distros or users excuses for sticking to the SSL-wise moldy
6.3.x releases.