I can successfully send messages via SMTP/SSL with Alpine 2.22 on a an Ubuntu 10.04 system with OpenSSL 1.1.1d. The SMTP Server is set to:

my-smtp-host:465/ssl/novalidate-cert/user=my-user-name.

When I use the same .pinerc, or configure a new .pinerc with the same settings, on a newer system (Ubuntu 20.04/OpenSSL 1.1.1f), with either Alpine 2.25 or Alpine 2.22, sending fails with "SSL negotiation failed". Debug information in the Alpine
journal shows only:

IMAP 11:39:56 11/6 mm_log babble: Trying IP address [my-smtp-ip]
sslfailure: host=my-smtp-host reason=SSL negotiation failed


Connections to the host from the newer system with OpenSSL s_client all succeed:
$ openssl s_client -starttls smtp -tls1_2 -connect my-smtp-host:465 CONNECTED(00000003)
$ openssl s_client -starttls smtp -tls1_1 -connect my-smtp-host:465 CONNECTED(00000003)
$ openssl s_client -starttls smtp -tls1 -connect my-smtp-host:465 CONNECTED(00000003)

The SMTP host does not support Verbose SMTP posting, so I don't know how to gather more information.

Any ideas?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 6 Nov 2021, jpj wrote:

I can successfully send messages via SMTP/SSL with Alpine 2.22 on
a an Ubuntu 10.04 system with OpenSSL 1.1.1d. The SMTP Server is set
to:

my-smtp-host:465/ssl/novalidate-cert/user=my-user-name.
[...]
Connections to the host from the newer system with OpenSSL s_client all succeed:
$ openssl s_client -starttls smtp -tls1_2 -connect my-smtp-host:465 CONNECTED(00000003)

Dear Jpj,

here is one more relevant piece of information. The configuration

my-smtp-host:465/ssl/novalidate-cert/user=my-user-name.

cannot be tested with the openssl command

$ openssl s_client -starttls smtp -tls1_2 -connect my-smtp-host:465

you should remove the "-starttls smtp" part if you want to test it, but
then if you want to preserve "-starttls smtp" in the command you should
change the port to 587. I suspect openssl will still connect, but again, without real information it is not possible to help you. Good luck.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 6 Nov 2021, jpj wrote:

I can successfully send messages via SMTP/SSL with Alpine 2.22 on
a an Ubuntu 10.04 system with OpenSSL 1.1.1d. The SMTP Server is set
to:

my-smtp-host:465/ssl/novalidate-cert/user=my-user-name.

Dear Jpj,

I understand you want to protect information for whatever good reasons
you might have, but not telling us the exact server will not help us help
you. If you could, at least send me an email with the name of the server,
so I can try to rule out Alpine from this, or fix Alpine.

When I use the same .pinerc, or configure a new .pinerc with the
same settings, on a newer system (Ubuntu 20.04/OpenSSL 1.1.1f), with
either Alpine 2.25 or Alpine 2.22, sending fails with "SSL negotiation failed". Debug information in the Alpine journal shows only:

IMAP 11:39:56 11/6 mm_log babble: Trying IP address [my-smtp-ip]
sslfailure: host=my-smtp-host reason=SSL negotiation failed

Connections to the host from the newer system with OpenSSL s_client all succeed:
$ openssl s_client -starttls smtp -tls1_2 -connect my-smtp-host:465 CONNECTED(00000003)
$ openssl s_client -starttls smtp -tls1_1 -connect my-smtp-host:465 CONNECTED(00000003)
$ openssl s_client -starttls smtp -tls1 -connect my-smtp-host:465 CONNECTED(00000003)

To me this sounds like an openssl configuration issue. There is an
openssl.cnf file in your machine, so take a look into that. (I think they
put it in /etc). There is also a variable

encryption-protocol-range

in your .pinerc that you might want to check which value it has. Also
running "alpine -v" in the 2.25 binary might give relevant information.

The SMTP host does not support Verbose SMTP posting, so I don't
know how to gather more information.

The verbose information that Alpine collects is a record of its
conversation with the server. Since you have not connected to the server
there is no log to read, and it is not relevant for this problem anyway.

Other than what I have said here, I do not think there is anything else
that I can say. If you want us to help you, give us more information. Otherwise, I wish you can solve this issue quickly.

Thank you.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eduardo,

Thanks for pointing me in the right direction. It seems the DH key on the SMTP server is small, and newer versions of OpenSSL do not allow connections to it. I'm trying to get the sysadmins to fix it, but in the meantime, I've had to find
another SMTP server.

The relevant information in the s_client tests is "dh key too small" in:
140712169444672:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149

From the headers of a message sent via the older OpenSSL system, it looks like the key is 256 bits:
version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256

Newer OpenSSL versions seem to require >= 2048 bits.


JPJ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 27 Nov 2021, jpj wrote:

Eduardo,

Thanks for pointing me in the right direction. It seems the DH
key on the SMTP server is small, and newer versions of OpenSSL do not
allow connections to it. I'm trying to get the sysadmins to fix it, but
in the meantime, I've had to find another SMTP server.

Dear jpj,

There is a chance that you can just edit your openssl.cnf file. In
debian we had this discussion some time ago (ended by silence from Debian)
Take a look at this thread in case it is relevant to you.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959481

Chances are you can change this through a configuration option until your system administrators fix their server.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)