Comment 4 for bug 1989387

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…)