On Sun, 3 May 2020, Unit 193 wrote:
Thank you for including logs! The important line from the latter is as
follows:
sslfailure: host=imap.otenet.gr reason=SSL negotiation failed
Unfortunately that's not a lot of detail, so it's useful to use testssl
or `openssl s_client` to check what's going on here.
From that, I got
routines:ssl_choose_client_version:unsupported
protocol:../ssl/statem/statem_lib.c:1929:
as well as testssl noting a few things that weren't favorable, such as a
SHA1 cert, offering SSLv3 and TLSv1, etc. Alpine had a bunch of changes
with regards to TLS in the last release, namely for me it added SNI
support, and I wonder if it's now more strict.
I do not know what changes Debian makes to the compilation of Alpine, or
to Openssl, and both are relevant here. The server at imap.otenet.gr
supports as the highest protocol for encryption TLSv1. Today the minimum
that most servers support is TLSv1_1, and so you find commonly that
TLSv1_2 is also used. Rarely you find TLSv1_3, but that is the direction
in which we are going.
On the other hand Alpine will support encryptions protocol as the library
that was used to compile supports. That is the exculpatory part in Alpine.
So you have to look at the encryption protocols in the underlying openssl
library. If that library was compiled without support for TLSv1, then no
application that needs support for TLSv1 will fail. again, this is because
of the library, not the program.
Many linux distributors already distribute libraries that do not support
SSLv3, even though the source code that they use to build those libraries
supports such version of SSL. This is a choice distributors make, not the
person compiling Alpine. Maybe Debian builds their openssl only supporting
TLSv1_1 and above. I do not know, but that is something to investigate.
Finally, there is a way to protect alpine users directly. Any Alpine user
can disable encryption protocols that they do not wish to use. So, for
example, if Debian distributed a version of openssl that supported SSLv3,
a user that feels that this is insecure could disable completely the
negotiation of said protocol, and make the connection fail (in the way
that this connection is failing) after the TLSv1 negotiation fail. In
other words, one could make the negotiation fail even when both Alpine
(through openssl) and the server support SSLv3. This is configured in the
variable
Encryption Protocol Range =
which is an interval of encryption protocols that Alpine will try. The
default is "no_min,no_max", meaning that openssl should try to use any
protocol that is compiled into openssl, starting with the highest and
continuing down, until it finds one that works for the server and openssl.
All Alpine does in this case is to tell openssl what not to try. This
could also be a source of conflict, because the default value of this
option can be modified at compilation time (e.g.: Debian can disable some
protocols from the beginning, and I would advise Debian not to do that,
but let the user choose). You can learn more about this variable by
pressing M S C and once you find it, read its help text.
So, unless the person who built alpine played with the default for this
variable, or the person reporting this bug also played with this variable,
the answer here is that both openssl and the server were compiled with
disjoint versions of encryption protocols, and none of them support the
one the other supports. Hence Alpine fails to connect.
--
Eduardo
