stunnel4 refuses to connect to TLSv1.0 server

[Thorsten Glaser]

Version: 3:5.63-1build1

This is an Ubuntu-specific bug, it works in Debian with the OpenSSL configuration provided (I actually copied the config from a Debian sid box to the Ubuntu jammy box). It also used to work on older Ubuntu releases.

The following fails:

# stunnel4 xconf
2022.09.13 00:47:21 LOG5[ui]: stunnel 5.63 on x86_64-pc-linux-gnu platform
2022.09.13 00:47:21 LOG5[ui]: Compiled/running with OpenSSL 3.0.2 15 Mar 2022
2022.09.13 00:47:21 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,OCSP,PSK,SNI Auth:LIBWRAP
2022.09.13 00:47:21 LOG5[ui]: Reading configuration from file /root/xconf
2022.09.13 00:47:21 LOG5[ui]: UTF-8 byte order mark not detected
2022.09.13 00:47:21 LOG5[ui]: FIPS mode disabled
2022.09.13 00:47:21 LOG4[ui]: Service [tlsv1-client-stunnel] needs authentication to prevent MITM attacks
2022.09.13 00:47:21 LOG5[ui]: Configuration successful
2022.09.13 00:47:21 LOG5[0]: Service [tlsv1-client-stunnel] accepted connection
2022.09.13 00:47:21 LOG5[0]: s_connect: connected x.x.x.x:xxxxx
2022.09.13 00:47:21 LOG5[0]: Service [tlsv1-client-stunnel] connected remote server from 172.26.5.141:60348
2022.09.13 00:47:21 LOG3[0]: SSL_connect: ../ssl/statem/statem_lib.c:104: error:0A0000BF:SSL routines::no protocols available
2022.09.13 00:47:21 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

The test configuration is:

# cat xconf
client = yes
foreground = yes
connect = x.x.x.x:xxxxx
service = tlsv1-client-stunnel
socket = r:SO_KEEPALIVE=1
socket = r:TCP_KEEPCNT=4
socket = r:TCP_KEEPIDLE=40
socket = r:TCP_KEEPINTVL=5
#sslVersion = all
sslVersion = TLSv1
renegotiation = no
options = -NO_TLSv1

On Debian, it worked with “sslVersion = all” and no “options” line.

Connections with openssl(1) from the same Ubuntu jammy box *do* work, so this is a bug in/with stunnel:
# openssl s_client -CApath /etc/ssl/certs -connect x.x.x.x:xxxxx -quiet
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = xxxxx.example.com
verify return:1
<<< first line of response from server >>>
[…]

The OpenSSL configuration I use is (pretty much Debian standard except at the very end)… too long, I’m attaching /etc/ssl/openssl.cnf from that box.

[Thorsten Glaser (mirabilos)]

The Debian sid version, which works, is 3:5.63-1.1 so they differ only by a binNMU on the Ubuntu side and the following NMU on the Debian side:

stunnel4 (3:5.63-1.1) unstable; urgency=medium

  * Non-maintainer upload

  [ Simon Chopin ]
  * Fix autopkgtests on new OpenSSL versions (Closes: #1010698)

 -- Paul Gevers <email address hidden> Wed, 31 Aug 2022 21:59:52 +0200

I *highly* doubt that this is relevant.

[Thorsten Glaser (mirabilos)]

(If you need access to an identically configured server to test against, message me privately.)

[Thorsten Glaser (mirabilos)]

I found a workaround… there seems to be some trouble between OpenSSL 3 and stunnel.

client = yes
foreground = yes
connect = $server
service = xxx
socket = r:SO_KEEPALIVE=1
socket = r:TCP_KEEPCNT=4
socket = r:TCP_KEEPIDLE=40
socket = r:TCP_KEEPINTVL=5
sslVersion = all
ciphers = AES256-SHA:@SECLEVEL=1

The double trick here is:

• according to Kurt Roeckx, when not breaking the RNG, the DH key exchanges for TLSv1 were moved to seclevel 0, but the RSA-based ones are still available (I know I’ve got them working at 2 in Debian sid with s_client even) so force AES256-SHA which is available in the higher levels and supported by the server
• add @SECLEVEL=1 to make this work on *buntu (it should work with 2 in Debian, see above)

With this, I don’t even need to change sslVersion from all.

However, I still have…

MinProtocol = TLSv1
CipherString = DEFAULT:@SECLEVEL=1
Options = UnsafeLegacyRenegotiation

… in /etc/ssl/openssl.cnf and did not test which of these apply to stunnel now. (Can probably be replaced with stunnel’s reneg opt.) Note on Debian, Options = UnsafeLegacyServerConnect is better, but this doesn’t work on *buntu yet. (The server’s got the patch to disable all renegotiation applied anyway, but they haven’t made a way for the server to sigal that, either it supports the secure reneg extension or it’s considered insecure, meh…)