Re: sslproto "TLS1" Causes Encrypted Alert Packets.

Am 12.03.19 um 16:26 schrieb Ralph Corderoy:
> Hi,
>
> I've just added another host and user to my .fetchmailrc.
>
>     poll foo via mail.foo.example proto pop3
>     user "[email protected]" is ralph password "letmein"
>         ssl sslcertck sslproto "TLS1" sslcommonname "bar.foo.example"
>
> `fetchmail -c foo' successfully establishes a TLS1.2 connection, but
> after a flurry of encrypted application data, `Encrypted Alert' packets
> are exchanged and the connection closed.  Dropping the -c gives the same
> behaviour.  If I keep -c and change "TLS1" to "SSL23" then it doesn't
> happen

Ralph,

The thing is "TLS1" means "TLS v1.0 and v1.0 only" and will fail if the
server refuses TLSv1.0. TLS1 triggers a call through the
tls1_client_method() constructor to set up internal TLS structures,
whereas SSL23 uses whatever OpenSSL would auto-negotiate
(SSLv23_client_method() - and is a misnomer), with restrictions (such as
forbidding SSLv2 and possibly SSLv3, depending on version). I suspect
that's that.

If not, can you share details on your setup? Fetchmail version or Git
commit hash, SSL library provider and version?
Note that I neither try nor trust LibreSSL, so if you're using that, see
if the issue reproduces with OpenSSL.


I'd think code and TLS-support-quality wise, the tip of the legacy_64
branch from Git should be the best choice if you would bother with
installing the autotools/gettext and other stuff such as flex and GNU
bison.
(You wouldn't need these when installing from a formal tarball.
Auto-generated tarballs from the Git repo don't count, only those I get
from "make distcheck").
> Using s_client(1), I see the server is Dovecot.

Will s_client work if you restrict it to the same server and -tls1?

HTH

Matthias