Bug#959481: alpine: does not connect with TLS to smtp/imap server
On Wed, 13 May 2020, Βασίλειος A. Ζοῦκος wrote: I think that the problem has been solved and I would like to thank all of you for your prompt responses. I am glad to read the problem is solved, but I would like to encourage Debian to not to do this kind of changes by default in its encryption library. Instead, my adivce is that the reasons that lead to these changes be taken as a minimum of what Debian should support. There are many users that for valid reasosn cannot use more modern encryption protocols, and so when I support software, I have to support users to use the low encryption protocol if that is all they can afford, but make the default the high encryption protocols. That is what encryption libraries offer, and users should be able to pick using lower encryption protocols, if they so wish to, or only use high encryption protocols, if they can do so, but that should be a choice of a user on a case by case basis, not a blanket rule to apply to everyone. This is an example of what could happen when you decide to do so. We might see this experience become a FAQ if Debian continues to do this. -- Eduardo
Bug#959481: alpine: does not connect with TLS to smtp/imap server
Hi, Following the hint in the last paragraph of the file: /usr/share/doc/libssl1.1/NEWS.Debian.gz I changed the parameters in section [system_default_sect] of the file /etc/ssl/openssl.cnf as follows: +---+---+---+ VariableFrom: To: +---+---+---+ MinProtocol TLSv1.2 None CipherStringDEFAULT@SECLEVEL=2 DEFAULT +---+---+---+ After this change, the alpine ver. 2.22 works as expected (same as ver. 2.20) on my debian system with: # hostnamectl --- Static hostname: debian64-izoukos Icon name: computer-laptop Chassis: laptop Machine ID: 3fd0fab79bb149d884aa4d3167b9f307 Boot ID: 6ca89e4927d845dbb5637a7a3b44dd82 Operating System: Debian GNU/Linux 10 (buster) Kernel: Linux 4.9.0-9-amd64 Architecture: x86-64 --- I think that the problem has been solved and I would like to thank all of you for your prompt responses. Thanks and best regards! V. Z. On Tue, 12 May 2020, Unit 193 wrote: Howdy, I noticed that your initial report claims that you're running buster, but the version you are comparing the buster backport to is from oldstable. This means that rather than linking against the same version of openssl, the older version of alpine you're running is linked against openssl1.0 which is no longer in Debian. If you really are on buster, can you also try alpine 2.21 from the buster repos? One larger change with buster was that openssl changed the default minimum TLS version from TLSv1 to TLSv1.2. For full information see /usr/share/doc/libssl1.1/NEWS.Debian.gz ~Unit 193 Unit193 @ freenode Unit193 @ OFTC On Mon, 11 May 2020, Eduardo Chappa wrote: On Mon, 11 May 2020, Βασίλειος A. Ζοῦκος wrote:
Bug#959481: alpine: does not connect with TLS to smtp/imap server
Howdy, I noticed that your initial report claims that you're running buster, but the version you are comparing the buster backport to is from oldstable. This means that rather than linking against the same version of openssl, the older version of alpine you're running is linked against openssl1.0 which is no longer in Debian. If you really are on buster, can you also try alpine 2.21 from the buster repos? One larger change with buster was that openssl changed the default minimum TLS version from TLSv1 to TLSv1.2. For full information see /usr/share/doc/libssl1.1/NEWS.Debian.gz ~Unit 193 Unit193 @ freenode Unit193 @ OFTC On Mon, 11 May 2020, Eduardo Chappa wrote: On Mon, 11 May 2020, Βασίλειος A. Ζοῦκος wrote: Thanks for the informative responses. More information on the subject: 1. The variable Encryption Protocol Range appears only in alpine ver. 2.22 with the assignment: Encryption Protocol Range = Yes, and since you have not modified it, nor Debian did, that means that your version of Alpine supports all the encryption protocols supported by the underlying version of openssl. Now it is the job of the Debian maintainer to investigate which protocols were used to compile each of the versions of Openssl that were used to link against each version of Alpine. Let us wait for that report, and we can figure out what the next action will be. ~Unit 193 Unit193 @ freenode Unit193 @ OFTC
Bug#959481: alpine: does not connect with TLS to smtp/imap server
On Mon, 11 May 2020, Βασίλειος A. Ζοῦκος wrote: Thanks for the informative responses. More information on the subject: 1. The variable Encryption Protocol Range appears only in alpine ver. 2.22 with the assignment: Encryption Protocol Range = Yes, and since you have not modified it, nor Debian did, that means that your version of Alpine supports all the encryption protocols supported by the underlying version of openssl. Now it is the job of the Debian maintainer to investigate which protocols were used to compile each of the versions of Openssl that were used to link against each version of Alpine. Let us wait for that report, and we can figure out what the next action will be. -- Eduardo
Bug#959481: alpine: does not connect with TLS to smtp/imap server
Thanks for the informative responses. More information on the subject: 1. The variable Encryption Protocol Range appears only in alpine ver. 2.22 with the assignment: Encryption Protocol Range = 2. Attached are the outputs of the commands: # ldd /usr/bin/alpine_2_20 # ldd /usr/bin/alpine_2_22 Thanks again for your help!linux-vdso.so.1 (0x7ffc7c998000) libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f09effe1000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x7f09eff8d000) libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x7f09efb27000) libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x7f09ef8be000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f09ef892000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x7f09ef881000) libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x7f09ef86e000) libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f09ef78e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f09ef76d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f09ef5ac000) libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7f09ef578000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f09ef572000) libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f09ef561000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f09ef55c000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7f09ef555000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f09ef53b000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x7f09ef51e000) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x7f09ef372000) libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x7f09ef345000) /lib64/ld-linux-x86-64.so.2 (0x7f09f092d000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f09ef216000) libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x7f09ef1f7000) libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x7f09ef073000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x7f09eee6) libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x7f09eee26000) libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x7f09eeded000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f09eed6a000) libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x7f09eed62000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f09eed58000) linux-vdso.so.1 (0x7ffe9d86) libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7fb55fe4e000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7fb55fe14000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x7fb55fdc) libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x7fb55fd2f000) libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7fb55fa45000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7fb55fa17000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x7fb55fa04000) libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7fb55f924000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb55f903000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb55f742000) libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7fb55f70e000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7fb55f708000) libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7fb55f6f7000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb55f6f2000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7fb55f6eb000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fb55f6d1000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x7fb55f6b4000) libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x7fb55f508000) /lib64/ld-linux-x86-64.so.2 (0x7fb5605dc000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7fb55f3d7000) libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x7fb55f3b8000) libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x7fb55f234000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x7fb55f021000)
Bug#959481: alpine: does not connect with TLS to smtp/imap server
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
Bug#959481: alpine: does not connect with TLS to smtp/imap server
Howdy, On Sun, 3 May 2020, Βασίλειος A. Ζοῦκος wrote: To be more precise: On the same machine with the same debian distribution, I retain two executable versions for alpine: 1. alpine ver. 2.20 2. alpine ver. 2.22 Using the same alpine configuration (for ver 2.20, 2.22): 1. I am able to connect via TLS to imap/smtp servers and perform all the e-mail tasks using alpine ver. 2.20 2. I can't connect via TLS to the same imap/smtp servers using alpine 2.22. Attached are parts of the pine-debug files produced by the command: alpine_2_XX -d 9 (XX=20,22) Many thanks, 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. This sounds like something one might want to contact upstream about, I don't think I've noticed anything on the list regarding an issue like this, though I could have missed it. ~Unit 193 Unit193 @ freenode Unit193 @ OFTC
Bug#959481: alpine: does not connect with TLS to smtp/imap server
On Sat, 2 May 2020, Unit 193 wrote:
severity -1 normal
tags -1 + unreproducible
stop
Howdy,
When filing bugs, please at the very least take the time to fill out the the
template additionally providing any details that may be used to assist with
your problem.
I have been using this version of alpine for some time now (indeed, it fixes
SNI issues) and have no problems connecting to TLS sources. Perhaps take a
minute to review your configuration and see if there's any oddities
preventing you from connecting, and if at all possible provide any details
that might further shed light on the problem.
~Unit 193
Unit193 @ freenode
Unit193 @ OFTC
To be more precise:
On the same machine with the same debian distribution, I retain two
executable versions for alpine:
1. alpine ver. 2.20
2. alpine ver. 2.22
Using the same alpine configuration (for ver 2.20, 2.22):
1. I am able to connect via TLS to imap/smtp servers and perform all the
e-mail tasks using alpine ver. 2.20
2. I can't connect via TLS to the same imap/smtp servers using alpine 2.22.
Attached are parts of the pine-debug files produced by the command:
alpine_2_XX -d 9 (XX=20,22)
Many thanks,
19:40:26.561978
Debug output of the Alpine program (debug=9 debug_imap=4). Version 2.20 (DEB 67
2015-01-07)
Thu Apr 30 19:40:26 2020
19:40:26.562098
Starting after the reading_pinerc calls, the data in this file should
be encoded as UTF-8. Before that it will be in the user's native charset.
19:40:26.562150
Debug file: /home/vzoukos/.pine-debug1 (level=9 imap=4)
19:40:26.562187
"/usr/bin/alpine_2_20" "-d" "9" (PID=1191)
19:40:26.562241
Setting home dir from $HOME: "/home/vzoukos"
19:40:26.571837
-- init_pinerc --
>>+ Ommited section
<<- Ommited section
19:40:31.787358
start_after() created c0d37700: done
19:40:31.787475
pine_mail_open: opening
"{imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX" (stream was
NULL) openflags=0x500 SP_USERFLDR SP_USEPOOL (19:40:31.787475)
19:40:31.787587
sp_stream_get({imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX):
SP_MATCH
19:40:31.787650
sp_stream_get: no match found
19:40:31.787709
sp_stream_get({imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX):
SP_SAME SP_TEMPUSE
19:40:31.787770
sp_stream_get: no match found
19:40:31.787827
pine_mail_open: there is an empty slot to use
19:40:32.007878
IMAP 19:40:32 4/30 mm_log babble: Trying IP address [62.103.147.209]
19:40:32.061157
IMAP DEBUG 19:40:32.061157: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR
LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] OTENET ready
19:40:32.061298
imap_cmd({imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX,
STARTTLS, 0x0)
19:40:32.061385
IMAP DEBUG 19:40:32.061385: STARTTLS
19:40:32.082356
IMAP DEBUG 19:40:32.082356: OK Begin TLS negotiation now.
19:40:32.149887
imap_cmd({imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX,
CAPABILITY, 0x0)
19:40:32.150002
IMAP DEBUG 19:40:32.150002: 0001 CAPABILITY
19:40:32.170860
IMAP DEBUG 19:40:32.170860: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR
LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN
19:40:32.170942
IMAP DEBUG 19:40:32.170942: 0001 OK Pre-login capabilities listed,
post-login capabilities have more.
19:40:32.195544
IMAP DEBUG 19:40:32.195544: 0002 AUTHENTICATE PLAIN
19:40:32.218606
IMAP DEBUG 19:40:32.218606: +
19:40:32.218719
mm_login_work trial=0 user=vzoukos service=imap
19:40:32.218790
mm_login: host=imap.otenet.gr
19:40:32.218850
imap_get_passwd: checking user=vzoukos alt=1 host=imap.otenet.gr
19:40:32.218911
imap_get_passwd: no match
19:40:32.218968
read_passfile
19:40:32.219027
Looking for passfile "/home/vzoukos/.pine-passfile"
19:40:32.219154
=== optionally_enter called ===
>>+ Ommited section
<<- Ommited section
19:40:03.172282
Debug output of the Alpine program (debug=9 debug_imap=4). Version 2.22 (DEB
394 2020-01-19)
Thu Apr 30 19:40:03 2020
19:40:03.172405
Starting after the reading_pinerc calls, the data in this file should
be encoded as UTF-8. Before that it will be in the user's native charset.
19:40:03.172456
Debug file: /home/vzoukos/.pine-debug1 (level=9 imap=4)
19:40:03.172498
"/usr/bin/alpine" "-d" "9" (PID=1185)
19:40:03.172554
Setting home dir from $HOME: "/home/vzoukos"
19:40:03.181443
-- init_pinerc --
>>+ Ommited section
<<- Ommited section
19:40:10.252281
start_after() created ba738700: done
19:40:10.252371
pine_mail_open: opening
"{imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX" (stream was
NULL) openflags=0x500 SP_USERFLDR SP_USEPOOL (19:40:10.252371)
19:40:10.252459
sp_stream_get({imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX):
SP_MATCH
19:40:10.252522
sp_stream_get: no match found
19:40:10.252581
sp_stream_get({imap.otenet.gr/IMAP/novalidate-cert/norsh/user=vzoukos}INBOX):
SP_SAME SP_TEMPUSE
19:40:10.252642
sp_stream_get: no match
Bug#959481: alpine: does not connect with TLS to smtp/imap server
severity -1 normal tags -1 + unreproducible stop Howdy, When filing bugs, please at the very least take the time to fill out the the template additionally providing any details that may be used to assist with your problem. I have been using this version of alpine for some time now (indeed, it fixes SNI issues) and have no problems connecting to TLS sources. Perhaps take a minute to review your configuration and see if there's any oddities preventing you from connecting, and if at all possible provide any details that might further shed light on the problem. ~Unit 193 Unit193 @ freenode Unit193 @ OFTC
Bug#959481: alpine: does not connect with TLS to smtp/imap server
Package: alpine Version: 2.22+dfsg1-1~bpo10+1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? I expected to work properly as version 2.20 does *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/2 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages alpine depends on: ii libc6 2.28-10 ii libgssapi-krb5-2 1.17-3 ii libkrb5-3 1.17-3 ii libldap-2.4-2 2.4.47+dfsg-3+deb10u1 ii libssl1.1 1.1.1c-1 ii libtinfo6 6.1+20181013-2+deb10u1 ii mlock 8:2007f~dfsg-6 Versions of packages alpine recommends: ii alpine-doc 2.21+dfsg1-1.1 ii sensible-utils 0.0.12 Versions of packages alpine suggests: ii aspell 0.60.7~20110707-6 ii exim4-daemon-light [mail-transport-agent] 4.92-8+deb10u3 -- no debconf information
