- stunnel-users - stunnel.org

Re: stunnel 5.82 released
by Peter Pentchev 18 Sep '26

18 Sep '26

On Fri, Sep 18, 2026 at 12:01:00PM +0300, Peter Pentchev wrote: > On Thu, Sep 17, 2026 at 06:53:56PM +0200, Michał Trojnara via stunnel-users wrote: > > Dear Users, > > > > I have released version 5.82 of stunnel. > > > > ### Version 5.82, 2026.09.17, urgency: MEDIUM > > * Bugfixes > > - Fixed premature connection closure on macOS when the peer half-closed > > the plaintext connection while data still needed to be forwarded. > > * Features > > - Build compatibility with LibreSSL 4.3.2 (thanks to Masahito Yamaga). > > > > Home page: https://www.stunnel.org/ > > > > Download: https://www.stunnel.org/downloads.html > > > > SHA-256 hashes: > > > > 8e7438ccd6b3a2ab05182d0846e112a56a7f557ecdee40de07bf67820008bef7 > > stunnel-5.82.tar.gz > > 722c1ad626919af2b0034666b4d19cc4795e925c32f60e8f3c59af4fb3ad2dfc > > stunnel-5.82-win64-installer.exe > > e5bdb7fefaac57afebd8276165b2c69b92b4e717d0a00302d2431541936cb60a > > stunnel-5.82-android.zip > > Hi, > > Thanks for your work, and for the quick fixes! > > Is it on purpose that there is in OpenPGP signature for the source ...of course that is "...that there is no OpenPGP signature..." > tarball for 5.82? I'm not saying there has to be, just figuring out > whether that is your new release process. G'luck, Peter -- Peter Pentchev roam(a)ringlet.net roam(a)debian.org peter(a)morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

2 1

stunnel 5.82 released
by Michał Trojnara 17 Sep '26

17 Sep '26

Dear Users, I have released version 5.82 of stunnel. ### Version 5.82, 2026.09.17, urgency: MEDIUM * Bugfixes - Fixed premature connection closure on macOS when the peer half-closed the plaintext connection while data still needed to be forwarded. * Features - Build compatibility with LibreSSL 4.3.2 (thanks to Masahito Yamaga). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 8e7438ccd6b3a2ab05182d0846e112a56a7f557ecdee40de07bf67820008bef7 stunnel-5.82.tar.gz 722c1ad626919af2b0034666b4d19cc4795e925c32f60e8f3c59af4fb3ad2dfc stunnel-5.82-win64-installer.exe e5bdb7fefaac57afebd8276165b2c69b92b4e717d0a00302d2431541936cb60a stunnel-5.82-android.zip Best regards, Mike

1 0

stunnel 5.81 released
by Michał Trojnara 16 Sep '26

16 Sep '26

Dear Users, I have released version 5.81 of stunnel. ### Version 5.81, 2026.09.16, urgency: HIGH * Security bugfixes - OpenSSL DLLs updated to version 3.5.8. - Fixed truncation and out-of-bounds reads when inheriting binary session ticket keys containing null bytes (thanks to Jose A. Diaz). - Prevented OCSP stapling response failures from terminating the daemon (thanks to Jose A. Diaz). * Bugfixes - Avoided spurious sysconf error messages after successful descriptor-limit queries on platforms where a successful call may change errno. - Fixed a potential crash when parsing empty ASCII PSK secrets (thanks to Jose A. Diaz). - Fixed a memory leak after DTLS listener poll errors and timeouts (thanks to Jose A. Diaz). - Fixed memory leaks during NTLM HTTP proxy negotiation (thanks to Jose A. Diaz). - Fixed early startup logging before thread lock initialization (thanks to Jose A. Diaz). - Rejected excessively nested configuration includes instead of consuming the process stack recursively. * Features - Improved TLS and DTLS shutdown diagnostics. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 1d1b48fa26a06a5a035ca5ddc7377c75d5d78ad6f3b4886352a84818c854f932 stunnel-5.81.tar.gz ec16df6313dced7c84f20dbb9c677847d0a5219bdd35ab40cde18c135abd0411 stunnel-5.81-win64-installer.exe 5eec038e3a9c44d135942c2486ffa5156c02cfcf31bb5b7a65c6134c459a49f9 stunnel-5.81-android.zip Best regards, Mike

1 0

"perf.html" Performance Benchmark Details Needed
by Tom Li 02 Sep '26

02 Sep '26

Hi all. On the stunnel home page, https://www.stunnel.org/perf.html, the published benchmark claims that stunnel reaches 9-10 Gbps iperf3 throughput on a single flow on AMD Ryzen 9 7900. It also says, > The benchmark framework records every sample and the complete software environment > so future stunnel and OpenSSL releases can be compared using the same procedure However, I was unable to find this benchmark framework, which I wanted to use to retest stunnel's performance on different systems under the same condition. I was not able to test this framework in the "tests/" directory of the repository. Where can I find more information about the benchmark? Or, when will this benchmark framework be published? Thanks, Tom Li

1 0

CPU usage - stunnel waking up every 100 ms
by Ian Pilcher 02 Sep '26

02 Sep '26

I noticed that stunnel is constantly consuming 30% of one of my CPU cores. Looking at it with strace, I see that it is frequently (every 100 milliseconds?) waking up from a poll() system call, calling getpid() a couple of times and going back to sleep. [pid 3498] poll([{fd=6, events=POLLIN|POLLRDHUP}], 1, 100) = 0 (Timeout) [pid 3498] getpid() = 3494 [pid 3498] getpid() = 3494 [pid 3498] poll([{fd=6, events=POLLIN|POLLRDHUP}], 1, 100) = 0 (Timeout) [pid 3498] getpid() = 3494 [pid 3498] getpid() = 3494 [pid 3498] poll([{fd=6, events=POLLIN|POLLRDHUP}], 1, 100) = 0 (Timeout) [pid 3498] getpid() = 3494 [pid 3498] getpid() = 3494 [pid 3498] poll([{fd=6, events=POLLIN|POLLRDHUP}], 1, 100) = 0 (Timeout) [pid 3498] getpid() = 3494 [pid 3498] getpid() = 3494 AFAICT, this is a pipe that stunnel is using to talk to itself (maybe to communicate between threads)? # ls -l /proc/3498/fd total 0 lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 0 -> /dev/null lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 1 -> /dev/null lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 10 -> 'socket:[37674]' lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 11 -> 'socket:[37675]' lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 12 -> 'socket:[37676]' lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 2 -> /dev/null lr-x------. 1 stunnel stunnel 64 Aug 23 10:12 4 -> 'pipe:[38360]' l-wx------. 1 stunnel stunnel 64 Aug 23 10:12 5 -> 'pipe:[38360]' lr-x------. 1 stunnel stunnel 64 Aug 23 10:12 6 -> 'pipe:[38361]' l-wx------. 1 stunnel stunnel 64 Aug 23 10:12 7 -> 'pipe:[38361]' lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 8 -> 'socket:[37672]' lrwx------. 1 stunnel stunnel 64 Aug 23 10:12 9 -> 'socket:[37673]' Is this expected behavior? Anything that can be done about it? Environment: ============ stunnel 5.80 on x86_64-redhat-linux-gnu platform Compiled/running with OpenSSL 3.5.7 9 Jun 2026 Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI,DTLS Global options: fips = no RNDbytes = 1024 RNDfile = /dev/urandom RNDoverwrite = yes Service-level options: ciphers = PROFILE=SYSTEM (with "fips = yes") ciphers = PROFILE=SYSTEM (with "fips = no") ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 (with TLSv1.3) curves = P-256:P-521:P-384 (with "fips = yes") curves = X25519MLKEM768:X25519:P-256:X448:P-521:P-384 (with "fips = no") debug = daemon.notice logId = sequential options = NO_SSLv2 options = NO_SSLv3 securityLevel = 2 sessionCacheSize = 1000 sessionCacheTimeout = 300 seconds stack = 131072 bytes TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds TIMEOUTocsp = 5 seconds verify = none stunnel.conf: ============= debug = warning [switch2-frontend] accept = 0.0.0.0:8402 CAfile = /etc/ipa/ca.crt cert = /etc/pki/tls/certs/stunnel/switch2.crt key = /tmp/keys/switch2.key connect = 127.255.255.254:8082 [switch2-backend] client = yes accept = 127.255.255.254:8082 connect = 172.31.4.2:443 verifyChain = yes checkHost = switch2.penurio.us CAfile = /etc/pki/tls/certs/stunnel/switch-ca.crt sslVersion = TLSv1 ciphers = DHE-RSA-AES256-SHA options = ALLOW_UNSAFE_LEGACY_RENEGOTIATION securityLevel = 0 OCSPrequire = no OCSPaia = no [switch4-frontend] accept = 0.0.0.0:8404 CAfile = /etc/ipa/ca.crt cert = /etc/pki/tls/certs/stunnel/switch4.crt key = /tmp/keys/switch4.key connect = 127.255.255.254:8084 [switch4-backend] client = yes accept = 127.255.255.254:8084 connect = 172.31.4.7:443 verifyChain = yes checkHost = switch4.penurio.us CAfile = /etc/pki/tls/certs/stunnel/switch-ca.crt sslVersion = TLSv1 ciphers = DHE-RSA-AES256-SHA options = ALLOW_UNSAFE_LEGACY_RENEGOTIATION securityLevel = 0 OCSPrequire = no OCSPaia = no -- ======================================================================== If your user interface is intuitive in retrospect ... it isn't intuitive ========================================================================

4 7

[PATCH 0/3] LDAP server-side STARTTLS support
by Steffen Heil | secforge 16 Aug '26

16 Aug '26

Hi Michal, This series adds server-side STARTTLS support for the LDAP protocol handler (RFC 2830). Three patches are attached: 0001 — core feature (src/protocol.c only) 0002 — automated test plugin for make check 0003 — optional Docker-based live integration test [RFC] Background ---------- stunnel already supports LDAP STARTTLS on the client side (ldap_client_middle): it connects to an LDAP backend, sends a StartTLS ExtendedRequest, waits for the success response, and then performs the TLS handshake toward the backend. The server side was missing. Without it, stunnel could not act as a TLS termination proxy in front of a plain LDAP backend for clients that initiate connections using STARTTLS — a common deployment pattern where legacy LDAP clients that do not support LDAPS (TLS-on-connect) still expect to negotiate TLS via STARTTLS before sending credentials. Patch 1 — core feature ----------------------- Two new functions in src/protocol.c, mirroring the structure of the existing client-side implementation: ldap_server_init Sets connect_before_ssl=1 so stunnel establishes the TCP connection to the backend before starting the TLS handshake with the local client. ldap_server_middle Reads the incoming LDAPMessage from the client and validates it as a StartTLS ExtendedRequest (APPLICATION 23, OID 1.3.6.1.4.1.1466.20037). Extracts the messageID and sends back a well-formed StartTLS ExtendedResponse (APPLICATION 24, resultCode=success) with the matching messageID. stunnel then performs SSL_accept with the client. WinLDAP-style four-byte length encoding is handled, matching the existing client-side behaviour. Both functions are registered in the PROTOCOL dispatch table under the existing "ldap" name, so protocol = ldap now works for both client and server services. Patch 2 — automated tests -------------------------- p28_ldap_starttls.py adds two tests to make check: Test 281: the Python test harness performs the RFC 2830 StartTLS exchange directly against a stunnel server (protocol=ldap), then upgrades to TLS via asyncio's loop.start_tls(), exercising ldap_server_middle in isolation. Test 282: a full client→server proxy chain where both stunnel instances run with protocol=ldap, exercising ldap_client_middle and ldap_server_middle together end-to-end. Patch 3 — live integration test [RFC / optional] ------------------------------------------------- ldap_starttls_live_test.sh is a shell script that runs against a real OpenLDAP server (osixia/openldap) in Docker. It requires Docker, ldapsearch/ldapadd, and openssl, so it is not part of make check. I'm sending it as an optional follow-up in case it is useful for manual verification or as a starting point for a CI stage. Feel free to drop it if it does not fit the project's test infrastructure. License ------- I dedicate my contributions in this patch series to the public domain, in line with the contribution policy stated in CREDITS.md. Regards, Steffen Heil Geschäftsführer _______________________________________________________________________________ secforge GmbH Starterzentrum | Campus A1.1 | 66123 Saarbrücken | Deutschland Phone: +49 179 2339260 | +49 681 93355440 E-Mail: steffen.heil(a)secforge.de<mailto:steffen.heil@secforge.de> Web: https://www.secforge.de Registergericht: Amtsgerichts Saarbrücken | HRB 109882 Geschäftsführer: Steffen Heil, Dr. Mikhail Kovalev

1 1

stunnel 5.80 released
by Michał Trojnara 04 Aug '26

04 Aug '26

Dear Users, I have released version 5.80 of stunnel. This is a security bugfix release. Details are available on: * https://www.stunnel.org/CVE-2026-70368.html * https://www.stunnel.org/CVE-2026-70367.html ### Version 5.80, 2026.08.04, urgency: HIGH * Security bugfixes - CVE-2026-70368: Fixed an out-of-bounds memory access triggered by logging attacker-controlled protocol messages longer than 1,024 bytes (thanks to AISLE Research and Clemens Lang). - CVE-2026-70367: Fixed a SOCKS server mode bypass of the localhost destination filter using alternate local-address encodings and interface-scoped IPv6 destinations (thanks to AISLE Research and Clemens Lang). - Restricted Windows GUI/service control pipes to local clients. * Bugfixes - Fixed concurrent DTLS handshakes from clients sharing an IP address. - Fixed version reporting in builds from source. - Rejected stream-oriented protocol negotiation with the UDP transport during configuration validation. * Features - Added the "CRLcheckChain" service-level option for opt-in full-chain CRL verification. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 6d0841d48de07cbbaf4a055919065bf7bb5ebc63cc15c97a2c76caa2bf285513 stunnel-5.80.tar.gz 25947bd268e2e670e1c7f915cefd54585aaa440d09eb20c6109cdbeaf3140bc4 stunnel-5.80-win64-installer.exe 15a36d8641bcf885f13ce0ee858d1f07bf4798824093e54fd00eeeb526dcc5ab stunnel-5.80-android.zip Best regards, Mike

1 0

FW: Re: client UDP 5093 -> TCP 5555 and vice versa in Server (TCP 5555 -> UDP 5093)
by admin＠igram.gr 05 Jul '26

05 Jul '26

Thank you Jochen and apologies for the delayed reply; I was out of the office for long time. When I received your reply, I immediately tried to follow your advice regarding socat. Unfortunately, however, it didn't work for me... At first, I thought the issue might be Windows-related, so I installed Cygwin, but that didn't help either. The problem most likely lay in the client-server communication and back within SPSS. Perhaps installing socat on both ends would have made it work. However, the instructions were not to install anything on the client side-ONLY on the server. I could modify the SPSS license software on the server (the communication part), but I couldn't make *any* changes on the client side...!!! ---- So, I settled on using a reverse proxy to handle the packet "translation" (I used a token for server authentication to get around the UDP issue, while keeping the client-side setup completely "dumb" - just using a DNS record to route traffic through the reverse proxy). It was a bit of a hack, but it worked... I would have preferred a more in-house solution, but I didn't have the time and needed to move forward. ---- Thanks again for your reply with socat proposal. It will definitely come in handy for another application that doesn't have the same software-imposed limitations. BR John NSS -----Original Message----- From: Jochen Bern via stunnel-users [mailto:stunnel-users@lists.stunnel.org] Sent: Κυριακή, 19 Απριλίου 2026 22:51 To: stunnel-users(a)lists.stunnel.org Subject: [stunnel-users] Re: client UDP 5093 -> TCP 5555 and vice versa in Server (TCP 5555 -> UDP 5093) Am 19.04.26 um 02:46 schrieb admin--- via stunnel-users: > So the question is of it is possible with stunnel to convert / wrap > e.g. by users the UDP port 5093, to "convert" it to TCP e.g. 5555 stunnel does only TCP. socat *may* be able to do that conversion (it knows both UDP and TCP and the manpage doesn't seem to specifically rule the combo out, but I didn't try it), but I would expect the resulting packets to have subtle changes that the software might balk at. A *license* service *should* try to reject manipulated/simulated peers, after all. NATing UDP traffic to a different UDP port that the firewall lets pass would IMHO be preferable, followed by proper tunneling (which includes variants that are "not quite a VPN yet"). Kind regards, -- Jochen Bern Systemingenieur Binect GmbH

1 0

stunnel 5.79 released
by Michał Trojnara 29 Jun '26

29 Jun '26

Dear Users, I have released version 5.79 of stunnel. ### Version 5.79, 2026.06.29, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 3.5.7. * Bugfixes - Fixed a TCP stream truncation (thanks to Solomon Jacobs). - Fixed a transfer() loop (thanks to Solomon Jacobs). - Fixed log reopening logs without a configured log file. - Fixed some logged values (thanks to Jose Alf.). - Fixed some error handling and cleanup issues (thanks to Jose Alf.). - Fixed OpenSSL applink detection and MSYS2 MinGW builds. * Features - Added the new 'transport' service-level option to choose between TLS over TCP and DTLS over UDP. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 8ea0de6e5ea76f38ea987fa831c7fd47f7a1f1e7dd465fd6fa8622edf30d3a45 stunnel-5.79.tar.gz 3d946e9759d5a6c6fc5aadb6b56e7de1a81d210ad028235340616e471afeb6f6 stunnel-5.79-win64-installer.exe 6257efc6c53af66541d6138e67d9377e050c13ad41880250dd43346c54127892 stunnel-5.79-android.zip Best regards, Mike

3 4

SSL_connect: Connection reset by peer (WSAECONNRESET) (10054)
by Graham Jones 04 Jun '26

04 Jun '26

I have one connection that works, and another which fails; but they have equivalent settings. Please help me resolve this. A fragment of the config for the connection that works: [Lopham-smtp] client = yes accept = 127.0.0.1:52025 connect = mail.lopham.co.uk:465 The server mail.lopham.co.uk is hosted by a service that I pay for. A fragment of the config for the connection that fails: [zen-smtp] client = yes accept = 127.0.0.1:26025 connect = mailhost.zen.co.uk:587 The failure in the log is 2026.06.02 12:22:48 LOG3[1]: SSL_connect: Connection reset by peer (WSAECONNRESET) (10054). The server mailhost.zen.co.uk is hosted by my internet connection provider (Zen Internet). When I make the connection without using stunnel the connection works OK. My SMTP settings in Outlook 2010 are: Server = mailhost.zen.co.uk Authentication = Yes Port = 576 Encryption = TLS So I set debug = 7 The log shows: 2026.06.02 12:22:48 LOG7[1]: Service [zen-smtp] started 2026.06.02 12:22:48 LOG7[1]: Setting local socket options (FD=504) 2026.06.02 12:22:48 LOG7[1]: Option TCP_NODELAY set on local socket 2026.06.02 12:22:48 LOG5[1]: Service [zen-smtp] accepted connection from 127.0.0.1:53292 2026.06.02 12:22:48 LOG6[1]: failover: priority, starting at entry #0 2026.06.02 12:22:48 LOG6[1]: s_connect: connecting 212.23.1.19:587 2026.06.02 12:22:48 LOG7[1]: s_connect: s_poll_wait 212.23.1.19:587: waiting 10 seconds 2026.06.02 12:22:48 LOG7[1]: FD=468 ifds=rw ofds=-- 2026.06.02 12:22:48 LOG5[1]: s_connect: connected 212.23.1.19:587 2026.06.02 12:22:48 LOG5[1]: Service [zen-smtp] connected remote server from 127.0.0.1:53293 2026.06.02 12:22:48 LOG7[1]: Setting remote socket options (FD=468) 2026.06.02 12:22:48 LOG7[1]: Option TCP_NODELAY set on remote socket 2026.06.02 12:22:48 LOG7[1]: Remote descriptor (FD=468) initialized 2026.06.02 12:22:48 LOG6[1]: SNI: sending servername: mailhost.zen.co.uk 2026.06.02 12:22:48 LOG7[1]: No previous session to resume 2026.06.02 12:22:48 LOG6[1]: Peer certificate required 2026.06.02 12:22:48 LOG7[1]: TLS state (connect): before SSL initialization 2026.06.02 12:22:48 LOG7[1]: TLS state (connect): SSLv3/TLS write client hello 2026.06.02 12:22:48 LOG3[1]: SSL_connect: Connection reset by peer (WSAECONNRESET) (10054) 2026.06.02 12:22:48 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2026.06.02 12:22:48 LOG7[1]: remote_fd reset (FD=468) 2026.06.02 12:22:48 LOG7[1]: Remote descriptor (FD=468) closed 2026.06.02 12:22:48 LOG7[1]: local_rfd/local_wfd reset (FD=504) 2026.06.02 12:22:48 LOG7[1]: Local descriptor (FD=504) closed 2026.06.02 12:22:48 LOG7[1]: Service [zen-smtp] finished (0 left) The log does not show me why the connection is reset by the peer. Can anybody help, please? Regards, == Graham

4 6