- stunnel-users - stunnel.org

[PATCH] Fix memory leak in create_pid() error path (src/ui_unix.c)
by Chhabra, Simranjeet Singh 08 Oct '26

08 Oct '26

Hello, While importing stunnel 5.82 we found a leak in create_pid() in src/ui_unix.c. If write() to the pid file comes up short, the function returns 1 without releasing the buffer allocated by str_printf(): ----- pid=str_printf("%lu\n", (unsigned long)getpid()); if(write(pf, pid, strlen(pid))<(int)strlen(pid)) { s_log(LOG_ERR, "Cannot write pid file %s", global_options.pidfile); ioerror("write"); (void)close(pf); return 1; /* pid is not released */ } str_free(pid); /* released on the success path */ (void)close(pf); ----- 5.82 added (void)close(pf) to this error path, which fixed the descriptor leak. The matching str_free(pid) is still missing, so the error path and the success path release different things. The impact is minor: this path is only reached at startup when the pid file cannot be written, and stunnel exits right after. Still, the fix is one line and makes both paths release the same resources. Patch against 5.82: ----- --- a/src/ui_unix.c +++ b/src/ui_unix.c @@ -284,6 +284,7 @@ NOEXPORT int create_pid(void) { if(write(pf, pid, strlen(pid))<(int)strlen(pid)) { s_log(LOG_ERR, "Cannot write pid file %s", global_options.pidfile); ioerror("write"); + str_free(pid); (void)close(pf); return 1; } ----- Could you consider this for the next release? If you would prefer the patch in a different form, I am happy to resend it. Best, Simranjeet Get Outlook for Mac<https://aka.ms/GetOutlookForMac>

1 0

"Connection reset by peer" Log Spam Issue with 5.82 on OS X
by H. Thiele 08 Oct '26

08 Oct '26

Hi there, I recently updated my stunnel installation from 5.70 to the latest 5.82, but an issue has popped up. Nothing else was changed on my system, just stunnel. In my case I use stunnel on an older OS X (yes, that's pre-"macOS") as glue between an outdated Mail client and the world "protected" with modern TLS. Basically Mail connects to stunnel locally which then does the "modern" TLS connection to various provider's mail servers (gmail, etc.) I use 'debug = 4' in stunnel.conf as long nothing is broken. With the old 5.70 the log usually stayed entirely silent that way. Now with 5.82 I see a lot of this: … 2026.10.07 23:03:00 LOG3[871]: transfer_tcp: SSL_read: Connection reset by peer (54) 2026.10.07 23:03:00 LOG3[866]: transfer_tcp: SSL_read: Connection reset by peer (54) 2026.10.07 23:03:00 LOG3[873]: transfer_tcp: SSL_read: Connection reset by peer (54) 2026.10.07 23:03:00 LOG3[869]: transfer_tcp: SSL_read: Connection reset by peer (54) 2026.10.08 01:11:57 LOG3[921]: transfer_tcp: SSL_read: Connection reset by peer (54) 2026.10.08 01:11:57 LOG3[925]: transfer_tcp: SSL_read: Connection reset by peer (54) … It seems to happen to about 20% of all connections/transfers. Investigating further with 'debug = 4' disabled/commented out: … 2026.10.06 18:33:50 LOG5[11]: Connection closed: 85 byte(s) sent to TLS, 264 byte(s) sent to socket 2026.10.06 18:33:50 LOG3[12]: transfer_tcp: SSL_read: Connection reset by peer (54) 2026.10.06 18:33:50 LOG5[12]: Connection reset: 85 byte(s) sent to TLS, 264 byte(s) sent to socket 2026.10.06 18:33:50 LOG3[13]: transfer_tcp: SSL_read: Connection reset by peer (54) 2026.10.06 18:33:50 LOG5[13]: Connection reset: 85 byte(s) sent to TLS, 264 byte(s) sent to socket … Note: #11 is OK, #12 and #13 have the error. Considering they all do the same: contact the server, ask for new mail, and (usually) get an answer of "no new mail" it looks like the error randomly pops up when things are finished? I don't notice any problems inside the Mail client, so all is OK at that end at least. I'm not sure if there's an actual problem here or if this is purely log noise. Any help appreciated. Thanks! regards, H. Thiele -- (a streamlined part of my stunnel.conf for reference) setuid = nobody setgid = nogroup foreground = yes output = /var/log/stunnel.log syslog = no debug = 4 client = yes CAfile = /usr/local/etc/openssl/cert.pem verifyChain = yes sslVersionMin = TLSv1.3 delay = yes [gmx-pop3] accept = 127.0.0.1:41001 connect = pop.gmx.com:995 checkHost = pop.gmx.com [gmx-smtp] accept = 127.0.0.1:41002 connect = mail.gmx.com:465 checkHost = mail.gmx.com [webde-pop3] accept = 127.0.0.1:41003 connect = pop3.web.de:995 checkHost = pop3.web.de [webde-smtp] accept = 127.0.0.1:41004 connect = smtp.web.de:465 checkHost = smtp.web.de [yahoo-pop3] accept = 127.0.0.1:41005 connect = pop.mail.yahoo.com:995 checkHost = pop.mail.yahoo.com [yahoo-smtp] accept = 127.0.0.1:41006 connect = smtp.mail.yahoo.com:465 checkHost = smtp.mail.yahoo.com [gmail-pop3] accept = 127.0.0.1:41007 connect = pop.gmail.com:995 checkHost = pop.gmail.com [gmail-smtp] accept = 127.0.0.1:41008 connect = smtp.gmail.com:465 checkHost = smtp.gmail.com [t-online-pop3] accept = 127.0.0.1:41009 connect = securepop.t-online.de:995 checkHost = securepop.t-online.de [t-online-smtp] accept = 127.0.0.1:41010 connect = securesmtp.t-online.de:465 checkHost = securesmtp.t-online.de ; … [cut the rest of the file for privacy reasons, but more services like above follow here] …

1 0

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:[email protected]> 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:[email protected]] 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