January 2025 - stunnel-users

stunnel - client conexion close by TLS alert (write) fatal decode error
by Rodigo Alvarez 07 Mar '25

07 Mar '25

Hi All! I would appreciate any clue to solve the problem we are having with a client mode service that stopped working this week (we verified that the service works directly without stunnel). The error I identify in the trace is the following: "TLS alert (write): fatal: decode error" Stunnel Config (windows version): [afip-prod-fce] client = yes accept = ARSASSRV4DMS06:1031 connect = serviciosjava.afip.gob.ar:443 debug = 7 ws: https://serviciosjava.afip.gob.ar/wsfecred/FECredService Complete trace: 2024.01.24 09:28:46 LOG5[main]: stunnel 5.71 on x64-pc-mingw32-gnu platform 2024.01.24 09:28:46 LOG5[main]: Compiled/running with OpenSSL 3.1.3 19 Sep 2023 2024.01.24 09:28:46 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI 2024.01.24 09:28:46 LOG5[main]: Reading configuration from file C:\Program Files (x86)\stunnel\config\stunnel.conf 2024.01.24 09:28:46 LOG5[main]: UTF-8 byte order mark detected 2024.01.24 09:28:46 LOG5[main]: FIPS mode disabled 2024.01.24 09:28:46 LOG4[main]: Service [afip-prod-fce] needs authentication to prevent MITM attacks 2024.01.24 09:28:46 LOG5[main]: Configuration successful 2024.01.24 09:29:23 LOG7[0]: Service [afip-prod-fce] started 2024.01.24 09:29:23 LOG7[0]: Setting local socket options (FD=892) 2024.01.24 09:29:23 LOG7[0]: Option TCP_NODELAY set on local socket 2024.01.24 09:29:23 LOG5[0]: Service [afip-prod-fce] accepted connection from 10.70.162.24:57723 2024.01.24 09:29:23 LOG6[0]: s_connect: connecting 200.1.116.19:443 2024.01.24 09:29:23 LOG7[0]: s_connect: s_poll_wait 200.1.116.19:443: waiting 10 seconds 2024.01.24 09:29:23 LOG7[0]: FD=896 ifds=rwx ofds=--- 2024.01.24 09:29:24 LOG5[0]: s_connect: connected 200.1.116.19:443 2024.01.24 09:29:24 LOG5[0]: Service [afip-prod-fce] connected remote server from 10.72.0.69:64788 2024.01.24 09:29:24 LOG7[0]: Setting remote socket options (FD=896) 2024.01.24 09:29:24 LOG7[0]: Option TCP_NODELAY set on remote socket 2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) initialized 2024.01.24 09:29:24 LOG6[0]: SNI: sending servername: serviciosjava.afip.gob.ar 2024.01.24 09:29:24 LOG6[0]: Peer certificate not required 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): before SSL initialization 2024.01.24 09:29:24 LOG7[0]: Initializing application specific data for session authenticated 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server key exchange 2024.01.24 09:29:24 LOG7[0]: OCSP stapling: Client callback called 2024.01.24 09:29:24 LOG6[0]: OCSP: Certificate chain verification disabled 2024.01.24 09:29:24 LOG6[0]: Client certificate not requested 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server done 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client key exchange 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read change cipher spec 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read finished 2024.01.24 09:29:24 LOG7[0]: New session callback 2024.01.24 09:29:24 LOG7[0]: Peer certificate was cached (6643 bytes) 2024.01.24 09:29:24 LOG6[0]: Session id: D63C79766AC02C9A3E8494AD528954A183E9F7C250856695BA05C16A2219A4B3 2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) requested 2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) succeeded 2024.01.24 09:29:24 LOG7[0]: 0 client renegotiation(s) requested 2024.01.24 09:29:24 LOG7[0]: 0 session reuse(s) 2024.01.24 09:29:24 LOG6[0]: TLS connected: new session negotiated 2024.01.24 09:29:24 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption) 2024.01.24 09:29:24 LOG6[0]: Peer temporary key: ECDH, P-256, 256 bits 2024.01.24 09:29:24 LOG7[0]: Compression: null, expansion: null 2024.01.24 09:29:24 LOG7[0]: Remove session callback 2024.01.24 09:29:24 LOG7[0]: TLS alert (write): fatal: decode error 2024.01.24 09:29:24 LOG6[0]: TLS socket closed (SSL_read) 2024.01.24 09:29:24 LOG7[0]: Sent socket write shutdown 2024.01.24 09:29:24 LOG5[0]: Connection closed: 1755 byte(s) sent to TLS, 634 byte(s) sent to socket 2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) closed 2024.01.24 09:29:24 LOG7[0]: Local descriptor (FD=892) closed 2024.01.24 09:29:24 LOG7[0]: Service [afip-prod-fce] finished (0 left) Thank you! Kind regards, Rodrigo.

3 3

stunnel warning: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number
by Marcel de Rooy 23 Jan '25

23 Jan '25

Hi, Taking this opportunity to ask a question on the mentioned warning. In our stunnel setup (stunnel server in a Docker container on Linux, version 5.68 and windows clients on version 5.73, no certificate verification) I am seeing every minute the following lines in stunnel.log on the server side: 2025.01.20 04:12:27 LOG5[0]: Service [siptest] accepted connection from 172.20.23.1:46658 2025.01.20 04:12:27 LOG3[0]: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number 2025.01.20 04:12:27 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket This is every minute, so 04:13:27 again, etc. The warning is there already shortly after container restart without active connections to our SIP devices. I only see it recently. And changing the server/client config with sslVersionMin = TLSv1.2 and sslVersionMax = TLSv1.3 did not resolve it. Since it comes back every minute, I was thinking in the direction of keepalive settings. But do keep alives need encryption? Probably not. Is this just an innocent bug in the stunnel code or could I still do something in my configuration to clear the warn? Thank you for your attention. Marcel de Rooy Rijksmuseum Netherlands xxx

3 4

How do I setup stunnel + openvpn for android (I already have the server running, I just need a android client, Sslsocks isn't working for some reason for me.)
by sharifkashif224＠gmail.com 22 Jan '25

22 Jan '25

I've tried using Sslsocks but it keeps giving me an error called unexpected eof while reading. This occurs when I try to initiate a connection via OpenVPN in android.

1 0

How do I use the android zip file provided in the download section in the stunnel website for android
by sharifkashif224＠gmail.com 22 Jan '25

22 Jan '25

I want to try connecting my openvpn server thats wrapped around stunnel onto my phone, any help will be appreciated!

1 0

Re: stunnel log file fills up with errors very fast
by Alan M Varghese (Nokia) 22 Jan '25

22 Jan '25

After digging into this a bit further, I was able to confirm that these "retries" are not created by stunnel itself. Rather, stunnel is simply trying to forward the connection attempts from NFS. Changing the NFS mount's "timeo" and "retrans" parameters affects duration for which NFS attempts to connect to the server. Thanks, Alan M Varghese

1 0

stunnel log file fills up with errors very fast
by Alan M Varghese (Nokia) 19 Jan '25

19 Jan '25

Hello stunnel users, With stunnel (version: 5.71) setup and running (used to secure NFSv4 mounts), when the network interface is brought down, a huge number of messages are written to the log file (configured with the "output" option) in a very short amount of time. Below are some sample logs: 2025.01.19 14:19:58 LOG5[1044766]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2025.01.19 14:19:58 LOG5[1044767]: Service [xxxxx] accepted connection from 127.0.0.1:994 2025.01.19 14:19:58 LOG3[1044767]: s_connect: connect 192.168.x.xx:xxxx: Network is unreachable (101) 2025.01.19 14:19:58 LOG3[1044767]: No more addresses to connect 2025.01.19 14:19:58 LOG5[1044767]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2025.01.19 14:19:58 LOG5[1044768]: Service [xxxxx] accepted connection from 127.0.0.1:994 2025.01.19 14:19:58 LOG3[1044768]: s_connect: connect 192.168.x.xx:xxxx: Network is unreachable (101) 2025.01.19 14:19:58 LOG3[1044768]: No more addresses to connect ... This causes the log size to grow very quickly, sometimes overwhelming the filesystem. Log rotation alleviates this issue to some extent. But still, the archived logs would be filled with duplicate logs. This issue has been discussed by another user in the following thread: https://www.stunnel.org/mailman3/hyperkitty/list/stunnel-users@stunnel.org/… (Note, while the user in the thread above received "Connection refused" messages, here the error is "Network is unreachable". Otherwise, the behaviour with respect to logs is the same.) We would like to know if there is a way to control this connection behaviour from stunnel when "Network is unreachable" in such a manner. If not, is there a way to control/limit the log output from stunnel (without reducing the log level from default)? Steps to reproduce the issue: 1. Mount an NFSv4 filesystem using stunnel (configured to output logs to a file) 2. Bring down the network interfaces such that stunnel is not able to reach the configured server. (Please make sure to not lose access to the server while doing this.) 3. Wait ~300 seconds 4. Bring the interface(s) back up. 5. Examine the log size and contents. Thanks, Alan M Varghese

1 0

Issue with OCSP messages in stunnel 5.73 and above
by Alexander Moisseev 02 Jan '25

02 Jan '25

Hello, I am experiencing an issue with stunnel versions 5.73 and above where the server logs are continuously filled with the following message: "OCSP: SSL_get_certificate" This issue does not occur in version 5.72. I am using PSK for encryption and have not configured OCSP. Here are the details of my setup: [.] stunnel 5.74 on amd64-portbld-freebsd14.1 platform [.] Compiled with OpenSSL 3.0.13 30 Jan 2024 [.] Running with OpenSSL 3.0.15 3 Sep 2024 - Server configuration file: ``` setuid = stunnel setgid = nogroup pid = /var/run/stunnel/stunnel.pid [bayes] accept = 6478 connect = 6378 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt cert = /usr/local/etc/stunnel/cert.pem key = /usr/local/etc/stunnel/private.key [fuzzy] accept = 6477 connect = 6377 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt cert = /usr/local/etc/stunnel/cert.pem key = /usr/local/etc/stunnel/private.key ``` - Client configuration file: ``` setuid = stunnel setgid = nogroup pid = /var/run/stunnel/stunnel.pid [bayes] client = yes accept = localhost:6478 connect = host.example.org:6478 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt [fuzzy] client = yes accept = localhost:6477 connect = host.example.org:6477 ciphers = PSK PSKsecrets = /usr/local/etc/stunnel/psk.txt ``` - Relevant log entries: ``` Dec 27 09:00:10 mx stunnel[22113]: LOG3[per-minute]: OCSP: SSL_get_certificate ``` As a temporary workaround, I generated a self-signed certificate and configured stunnel to use it. This has resolved the issue with OCSP messages. However, I believe this is not the intended behavior when using PSK without configuring OCSP. I would appreciate any help or guidance on how to properly configure stunnel to avoid this issue without requiring a self-signed certificate. Thank you, Alexander

3 4