- 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

Re: Stunnel Show Log Window
by Jose Alf. 31 May '26

31 May '26

Hi Graham, Yes. You are absolutely right. I was a bit confused with your question at first. I apologize. If we don't uncomment the output=filename.ext line, the log lines won't be written to any disk file. In this case, On Windows, the log lines go to the Log Window you mention. This is implemented as a circular buffer kept in RAM with hardcoded capacity for 1000 lines. That is, you will only see the last 1000 lines sent to the log and older lines are silently discarded. No crashes should happen. Best Regards,Jose -- On Sunday, May 31, 2026 at 10:57:37 AM GMT-5, Graham Jones <graham(a)lorien56.co.uk> wrote: Hi Jose, Thanks for the explanation about stunnel.log My config file has the line: ;output = stunnel.log I understand this to mean that the file stunnel.log is NOT created. And there is no evidence of this file anywhere. But the GUI allows me to see a "log window". So my question is: what happens when this "log window" fills up? Regards, == Graham > -----Original Message----- > From: Josealf.rm [mailto:josealf@rocketmail.com] > Sent: 31 May 2026 12:46 > To: Graham(a)lorien56.co.uk > Subject: Re: [stunnel-users] Stunnel Show Log Window > > Hi Graham, > > Stunnel does not implement automatic log rotation and it will not overwrite > earlier log entries. It will always try to append new entries at the end. By > default, the log file is named stunnel.log. If you run out of storage, stunnel > will probably crash. In Unix-like OSes like Linux or FreeBSD, you can configure > OS tasks to gracefully handle the log management. Periodically the stunnel > server process is stopped, the oldest log file is deleted and/or compressed > and the newest/current log is renamed. Then stunnel is started and a new > stunnel log is created. In Windows you could do something similar by creating > a suitable script or batch file and running it via Task Scheduler. > > Regards > Jose > > > > On 31/05/2026, at 1:26 AM, Graham Jones via stunnel-users <stunnel- > users(a)lists.stunnel.org> wrote: > > > > I'm new to Stunnel. > > > > stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro. > > > > I see the option to "Show Log Window". I have read the manual. I see > there > > is an option to specify an output file; I am not using this option. > > > > My question: > > > > When the space allocated to the log information fills up, what happens? > > Does stunnel overwrite the oldest log entries first? Or does it crash? > > > > Regards, > > > > == Graham > > > > > > _______________________________________________ > > stunnel-users mailing list -- stunnel-users(a)lists.stunnel.org > > To unsubscribe send an email to stunnel-users-leave(a)lists.stunnel.org

2 2

Stunnel Show Log Window
by Graham Jones 31 May '26

31 May '26

I'm new to Stunnel. stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro. I see the option to "Show Log Window". I have read the manual. I see there is an option to specify an output file; I am not using this option. My question: When the space allocated to the log information fills up, what happens? Does stunnel overwrite the oldest log entries first? Or does it crash? Regards, == Graham

2 1

Certificate rejected ...?
by Graham Jones 31 May '26

31 May '26

I'm new to Stunnel. stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro. During installation, the process walked me through the creation of a certificate. I have these settings: [Lopham-imap] client = yes accept = 127.0.0.1:52143 connect = mail.lopham.co.uk:993 CAfile = ca-certs.pem The connection succeeds. I add the following lines: verifyChain = yes checkHost = mail.lopham.co.uk OCSPaia = yes The connection fails with the following lines in the log: 2026.05.30 21:45:52 LOG5[2]: Service [Lopham-imap] accepted connection from 127.0.0.1:51901 2026.05.30 21:45:52 LOG5[2]: s_connect: connected 193.143.227.10:993 2026.05.30 21:45:52 LOG5[2]: Service [Lopham-imap] connected remote server from 127.0.0.1:51902 2026.05.30 21:45:52 LOG4[2]: CERT: Pre-verification error: certificate not found in local repository: self-signed certificate in certificate chain 2026.05.30 21:45:52 LOG4[2]: Rejected by CERT at depth=1: OU=generated by AVG Antivirus for SSL/TLS scanning, O=AVG Web/Mail Shield, CN=AVG Web/Mail Shield Root 2026.05.30 21:45:52 LOG3[2]: SSL_connect: tls_post_process_server_certificate@ssl/statem/statem_clnt.c:2124: error:0A000086:SSL routines::certificate verify failed: client 127.0.0.1:51901 2026.05.30 21:45:52 LOG5[2]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket I see it finds the self-signed certificate in certificate chain. Why is this rejected? Any ideas, please? Regards, == Graham

3 3

stunnel works but only with debug on
by Graham Jones 28 May '26

28 May '26

I'm new to stunnel. stunnel 5.78 on x64-pc-mingw32-gnu platform Windows 7 Pro Using Outlook to open a connection to a POP server Extract from stunnel.conf [Zen-pop3] client = yes accept = 127.0.0.1:110 connect = mailhost.zen.co.uk:995 CAfile = ca-certs.pem With debug = 7 the test succeeds. The log shows: 2026.05.13 16:49:06 LOG5[4]: Service [Zen-pop3] accepted connection from 127.0.0.1:49596 2026.05.13 16:49:06 LOG5[4]: s_connect: connected 212.23.1.19:995 2026.05.13 16:49:06 LOG5[4]: Service [Zen-pop3] connected remote server from 127.0.0.1:49598 2026.05.13 16:49:06 LOG5[4]: Connection closed: 59 byte(s) sent to TLS, 202 byte(s) sent to socket With ;debug a test connection fails after about 20 seconds delay. Log extract: 2026.05.13 17:22:05 LOG5[6]: Service [Zen-pop3] accepted connection from 127.0.0.1:53162 2026.05.13 17:22:05 LOG5[6]: s_connect: connected 212.23.1.11:995 2026.05.13 17:22:05 LOG5[6]: Service [Zen-pop3] connected remote server from 127.0.0.1:53163 2026.05.13 17:22:26 LOG3[6]: SSL_connect: Connection reset by peer (WSAECONNRESET) (10054) Why does it only work with debug enabled? Any ideas, please? Regards, == Graham

2 1

client UDP 5093 -> TCP 5555 and vice versa in Server (TCP 5555 -> UDP 5093)
by admin＠igram.gr 19 Apr '26

19 Apr '26

Hi, I have a project where several students with IBM SPSS installed need to connect to a server where the IBM SPSS Network License Manager (Sentinel RMS) is installed and it requires that UDP port 5093 be open on the server's firewall to allow the clients to communicate and retrieve licenses. In my case this is not allowed in the firewall and I am trying to find solutions. One solution is to create VPN users to ensure that only allowed clients can communicate on this port (UDP 5093). But I prefer to keep the port closed for everyone. 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 thus bypassing the firewall policy on the server side (TCP/UDP 5093 is not allowed), and on the server side to do the reverse, i.e. the "conversion" from TCP 5555 to UDP 5093 or is it a stupid idea? Has anyone done a similar project? THX John

2 1

[PATCH] checkPurpose configuration to circumvent EKU
by stunnel＠benary.org 14 Apr '26

14 Apr '26

From: benaryorg <binary(a)benary.org> What this does in a nutshell is to allow to use client certificates for servers, and server certificates for clients. This has become a relevant workaround for people using Let's Encrypt certificates for mutual TLS authentication (i.e. checkHost on both sides). Let's Encrypt, due to pressure from Google, have disabled client usage in their certificates, thereby causing issues in the latest renewals. https://letsencrypt.org/2025/05/14/ending-tls-client-authentication Any connections initiated by a client using a server certificate as to authenticate against a server cause a "unsuitable certificate purpose" on the server side and a TLS termination on the client side. This patch allows to simply override this check, for better or for worse. An earlier version was written with `checkPurpose` being allowed to occur multiple times (like `checkHost` and friends). However the value set does not support binary OR (it is simply sequentially numbered). Signed-off-by: benaryorg <binary(a)benary.org> --- doc/stunnel.8.in | 7 +++++++ doc/stunnel.html.in | 8 ++++++++ doc/stunnel.pod.in | 8 ++++++++ src/options.c | 35 +++++++++++++++++++++++++++++++++++ src/prototypes.h | 1 + src/verify.c | 3 +++ 6 files changed, 62 insertions(+) diff --git a/doc/stunnel.8.in b/doc/stunnel.8.in index db02292..4450715 100644 --- a/doc/stunnel.8.in +++ b/doc/stunnel.8.in @@ -460,6 +460,13 @@ addresses specified with \fIcheckIP\fR. Multiple \fIcheckIP\fR options are allowed in a single service section. .Sp This option requires OpenSSL 1.0.2 or later. +.IP "\fBcheckPurpose\fR = default | any | client | server" 4 +.IX Item "\fBcheckPurpose\fR = default | any | client | server" +verify the Extended Key Usage of the peer certificate +.Sp +Certificate verification only succeeds if the certificate purpose, +specifically the Extended Key Usage, matches the parameters specified with +\fIcheckPurpose\fR. .IP "\fBciphers\fR = CIPHER_LIST" 4 .IX Item "ciphers = CIPHER_LIST" select permitted TLS ciphers (TLSv1.2 and below) diff --git a/doc/stunnel.html.in b/doc/stunnel.html.in index 90e8556..6eca48e 100644 --- a/doc/stunnel.html.in +++ b/doc/stunnel.html.in @@ -552,6 +552,14 @@ This option requires OpenSSL 1.0.2 or later. +</dd> +<dt id="checkPurpose-default-any-client-server">checkPurpose = default | any | client | server</dt> +<dd> + +verify the Extended Key Usage of the peer certificate + +Certificate verification only succeeds if the certificate purpose, specifically the Extended Key Usage, matches the parameters specified with checkPurpose. + </dd> <dt id="ciphers-CIPHER_LIST">ciphers = CIPHER_LIST</dt> <dd> diff --git a/doc/stunnel.pod.in b/doc/stunnel.pod.in index 752359d..977a879 100644 --- a/doc/stunnel.pod.in +++ b/doc/stunnel.pod.in @@ -500,6 +500,14 @@ Multiple I<checkIP> options are allowed in a single service section. This option requires OpenSSL 1.0.2 or later. +=item B<checkPurpose> = default | any | client | server + +verify the Extended Key Usage of the peer certificate + +Certificate verification only succeeds if the certificate purpose, +specifically the Extended Key Usage, matches the parameters specified with +I<checkPurpose>. + =item B<ciphers> = CIPHER_LIST select permitted TLS ciphers (TLSv1.2 and below) diff --git a/src/options.c b/src/options.c index 800d1f3..2ed4111 100644 --- a/src/options.c +++ b/src/options.c @@ -1854,6 +1854,41 @@ NOEXPORT const char *parse_service_option(CMD cmd, SERVICE_OPTIONS **section_ptr break; } + /* checkPurpose */ + switch(cmd) { + case CMD_SET_DEFAULTS: + section->check_purpose=X509_PURPOSE_DEFAULT_ANY; + break; + case CMD_SET_COPY: + section->check_purpose=new_service_options.check_purpose; + break; + case CMD_FREE: + break; + case CMD_SET_VALUE: + if(strcasecmp(opt, "checkPurpose")) + break; + if(!strcasecmp(arg, "default")) { + section->check_purpose=X509_PURPOSE_DEFAULT_ANY; + } else if(!strcasecmp(arg, "any")) { + section->check_purpose=X509_PURPOSE_ANY; + } else if(!strcasecmp(arg, "client")) { + section->check_purpose=X509_PURPOSE_SSL_CLIENT; + } else if(!strcasecmp(arg, "server")) { + section->check_purpose=X509_PURPOSE_SSL_SERVER; + } else { + return "The argument needs to be one of: default, any, client, server"; + } + return NULL; /* OK */ + case CMD_INITIALIZE: + break; + case CMD_PRINT_DEFAULTS: + break; + case CMD_PRINT_HELP: + s_log(LOG_NOTICE, "%-22s = client|server check for extended key usage", + "checkPurpose"); + break; + } + #endif /* OPENSSL_VERSION_NUMBER>=0x10002000L */ /* ciphers */ diff --git a/src/prototypes.h b/src/prototypes.h index 1142993..fde3da9 100644 --- a/src/prototypes.h +++ b/src/prototypes.h @@ -303,6 +303,7 @@ struct service_options_struct { NAME_LIST *check_host, *check_email, *check_ip; /* cert subject checks */ NAME_LIST *config; /* OpenSSL CONF options */ #endif /* OPENSSL_VERSION_NUMBER>=0x10002000L */ + int check_purpose; /* Extended Key Usage */ /* service-specific data for ctx.c */ char *cipher_list; diff --git a/src/verify.c b/src/verify.c index 7bab21e..e7dfe9f 100644 --- a/src/verify.c +++ b/src/verify.c @@ -78,6 +78,9 @@ int verify_init(SERVICE_OPTIONS *section) { verify_mode|=SSL_VERIFY_FAIL_IF_NO_PEER_CERT; } SSL_CTX_set_verify(section->ctx, verify_mode, verify_callback); + if(section->check_purpose) { + SSL_CTX_set_purpose(section->ctx, section->check_purpose); + } auth_warnings(section); -- 2.53.0

2 2

stunnel 5.78 released
by Michał Trojnara 10 Apr '26

10 Apr '26

Dear Users, I have released version 5.78 of stunnel. ### Version 5.78, 2026.04.09, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 3.5.6. * Bugfixes - Fixed WIN32 transfer() loop errors with OOB TCP. - Fixed a memory leak introduced in version 5.73. - Build fix for systems without timegm() (thanks to Jose A. Diaz and Shubham Gupta). - Fixed a startup crash when both global (default) and service-level lists of values are configured for an option. * Features - Support for zstd and brotli compression with OpenSSL 3.2 and TLS 1.2 or older. - WIN32 OpenSSL build with zlib and zstd support. - Support for new "options" parameter values. - Less bloated errors on an invalid configuration file. - Documentation updated from Pod to Pandoc Markdown. - Removed support for OpenSSL versions older than 0.9.8. The final update for the OpenSSL 0.9.7 branch (0.9.7m) was issed on 23 Feb 2007. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 8727e53bb8b7528f850327a2a149158422c02183bc120d1d733cc65b1e2c349d stunnel-5.78.tar.gz 541700197ce2e03dd86b343d9cbf6434359cca9f44e6927fde1d2c76c355c3e6 stunnel-5.78-win64-installer.exe b585d0828165d2e317f3956f2657fa6fb265b34b3ff49181bf561acd8eea2500 stunnel-5.78-android.zip Best regards, Mike

5 6

Connecting to Oracle errors to Connection reset by peer (104)
by HERCEK, Marián 27 Mar '26

27 Mar '26

Hello. Anybody has working setup with Oracle (SQLPlus)? Mine ends up with "Connection reset by peer". Server pid = /var/run/stunnel-oracle.pid cert = /etc/stunnel/stunnel.pem debug = 7 output = /var/log/stunnel/stunnel.log client = no [oracle] accept = 1.2.3.4:11521 connect = 127.0.0.1:1521 stunnel -version Initializing inetd mode configuration stunnel 5.71 on x86_64-redhat-linux-gnu platform Compiled/running with OpenSSL 1.1.1k FIPS 25 Mar 2021 Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 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 = 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 = 65536 bytes TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds TIMEOUTocsp = 5 seconds verify = none Client debug = 7 output = stunnel.log client = yes [oracle] accept = 127.0.0.1:50102 connect = 1.2.3.4:11521 verifyChain = no stunnel 5.77 on x64-pc-mingw32-gnu platform Compiled/running with OpenSSL 3.5.5 27 Jan 2026 Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Global options: fips = no RNDbytes = 1024 RNDoverwrite = yes taskbar = yes Service-level options: ciphers = FIPS:!DH:!kDHEPSK (with "fips = yes") ciphers = HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK (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 = 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 Debug logs from server (client logs are similar) 2026.03.26 12:54:18 LOG7[main]: Found 1 ready file descriptor(s) 2026.03.26 12:54:18 LOG7[main]: FD=4 events=0x2001 revents=0x0 2026.03.26 12:54:18 LOG7[main]: FD=9 events=0x2001 revents=0x1 2026.03.26 12:54:18 LOG7[main]: Service [oracle] accepted (FD=3) from 4.5.6.7:54017 2026.03.26 12:54:18 LOG7[3]: Service [oracle] started 2026.03.26 12:54:18 LOG7[3]: Setting local socket options (FD=3) 2026.03.26 12:54:18 LOG7[3]: Option TCP_NODELAY set on local socket 2026.03.26 12:54:18 LOG5[3]: Service [oracle] accepted connection from 4.5.6.7:54017 2026.03.26 12:54:18 LOG6[3]: Peer certificate not required 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): before SSL initialization 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): before SSL initialization 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Decrypt session ticket callback 2026.03.26 12:54:18 LOG6[3]: Decrypted ticket for an authenticated session: yes 2026.03.26 12:54:18 LOG7[3]: SNI: no virtual services defined 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS read client hello 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write server hello 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write change cipher spec 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Decrypt session ticket callback 2026.03.26 12:54:18 LOG6[3]: Decrypted ticket for an authenticated session: yes 2026.03.26 12:54:18 LOG7[3]: SNI: no virtual services defined 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS read client hello 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write server hello 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 write encrypted extensions 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write finished 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): TLSv1.3 early data 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS read finished 2026.03.26 12:54:18 LOG7[3]: 4 server accept(s) requested 2026.03.26 12:54:18 LOG7[3]: 4 server accept(s) succeeded 2026.03.26 12:54:18 LOG7[3]: 0 server renegotiation(s) requested 2026.03.26 12:54:18 LOG7[3]: 2 session reuse(s) 2026.03.26 12:54:18 LOG7[3]: 3 internal session cache item(s) 2026.03.26 12:54:18 LOG7[3]: 0 internal session cache fill-up(s) 2026.03.26 12:54:18 LOG7[3]: 0 internal session cache miss(es) 2026.03.26 12:54:18 LOG7[3]: 0 external session cache hit(s) 2026.03.26 12:54:18 LOG7[3]: 0 expired session(s) retrieved 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: Generate session ticket callback 2026.03.26 12:54:18 LOG7[3]: Initializing application specific data for session authenticated 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: New session callback 2026.03.26 12:54:18 LOG6[3]: No peer certificate received 2026.03.26 12:54:18 LOG6[3]: Session id: 483B0F9A7D229A299E5FE0AF18B9BC00D26CFB781A363ABC612E6C8481EE8D11 2026.03.26 12:54:18 LOG7[3]: TLS state (accept): SSLv3/TLS write session ticket 2026.03.26 12:54:18 LOG6[3]: TLS accepted: previous session reused 2026.03.26 12:54:18 LOG6[3]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2026.03.26 12:54:18 LOG6[3]: Peer temporary key: X25519, 253 bits 2026.03.26 12:54:18 LOG7[3]: Compression: null, expansion: null 2026.03.26 12:54:18 LOG6[3]: Session id: 483B0F9A7D229A299E5FE0AF18B9BC00D26CFB781A363ABC612E6C8481EE8D11 2026.03.26 12:54:18 LOG6[3]: s_connect: connecting 127.0.0.1:1521 2026.03.26 12:54:18 LOG7[3]: s_connect: s_poll_wait 127.0.0.1:1521: waiting 10 seconds 2026.03.26 12:54:18 LOG7[3]: FD=6 events=0x2001 revents=0x0 2026.03.26 12:54:18 LOG7[3]: FD=11 events=0x2005 revents=0x1 2026.03.26 12:54:18 LOG5[3]: s_connect: connected 127.0.0.1:1521 2026.03.26 12:54:18 LOG6[3]: persistence: 127.0.0.1:1521 cached 2026.03.26 12:54:18 LOG5[3]: Service [oracle] connected remote server from 127.0.0.1:43694 2026.03.26 12:54:18 LOG7[3]: Setting remote socket options (FD=11) 2026.03.26 12:54:18 LOG7[3]: Option TCP_NODELAY set on remote socket 2026.03.26 12:54:18 LOG7[3]: Remote descriptor (FD=11) initialized 2026.03.26 12:54:18 LOG6[3]: TLS fd: Connection reset by peer (104) 2026.03.26 12:54:18 LOG6[3]: transfer: SSL_read: Socket is closed 2026.03.26 12:54:18 LOG6[3]: TLS socket closed (SSL_read) 2026.03.26 12:54:18 LOG7[3]: Sent socket write shutdown 2026.03.26 12:54:18 LOG5[3]: Connection closed: 190 byte(s) sent to TLS, 663 byte(s) sent to socket 2026.03.26 12:54:18 LOG7[3]: Deallocating application specific data for session connect address 2026.03.26 12:54:18 LOG7[3]: Remote descriptor (FD=11) closed 2026.03.26 12:54:18 LOG7[3]: Local descriptor (FD=3) closed 2026.03.26 12:54:18 LOG7[3]: Service [oracle] finished (0 left)

2 1

stunnel 5.76+ segfaults when CAfile/cert are specified
by George Pucea 11 Mar '26

11 Mar '26

Dear team, I'm getting segfault when starting a stunnel. Here is a script to reproduce it with alpine: incident_cf cat stunnel-segfault-crash.sh *#!/bin/bash* *#* *# Reproducer: stunnel 5.76+ segfaults when CAfile/cert are specified* *# both globally and per-section with identical values.* *#* *# Requirements: Docker* *#* *# Expected output:* *# Segmentation fault* *# Exit: 139* *#* *docker run --rm alpine:latest sh -c '* *apk add -q stunnel openssl &&* *mkdir -p /app/managed &&* *openssl req -x509 -newkey rsa:2048 -keyout /tmp/k.pem -out /tmp/c.pem -days 1 -noenc -subj /CN=test 2>/dev/null &&* *cat /tmp/c.pem /tmp/k.pem > /app/managed/cert.pem &&* *cp /tmp/c.pem /app/managed/ca-file.pem &&* *echo "stunnel version: $(stunnel -version 2>&1 | grep "^stunnel")" &&* *printf "foreground=yes\nverify=2\nCApath=/etc/ssl/certs\nCAfile=/app/managed/ca-file.pem\ncert=/app/managed/cert.pem\npid=/tmp/s.pid\n[c0]\nclient=yes\naccept=33195\nCAfile=/app/managed/ca-file.pem\ncert=/app/managed/cert.pem\nconnect=192.0.2.1:12195 <http://192.0.2.1:12195>\n" > /tmp/test.conf &&* *stunnel /tmp/test.conf 2>&1; echo "Exit: $?"* *'* The workaround *is* removing the per-section CAfile/cert (relying on global values). Is this a known bug? Where can I report it? Thanks!

2 1

Systemd journal log line issues
by u34＠net9.cf 05 Mar '26

05 Mar '26

This messgave could be related to the [systemd and stunnel.service](https://www.stunnel.org/mailman3/hyperkitty/list/stunnel-u… thread. With stunnel 5.77 from the official Debian package, and using instances of Debian systemd template, I am getting duplicate lines at the journal. Each line is duplicated, as in Mar 03 01:02:24 myhost stunnel[50237]: LOG5[ui]: Log file reopened Mar 03 01:02:24 myhost stunnel4[50237]: 2026.03.03 01:02:24 LOG5[ui]: Log file reopened The order of those lines can be reversed in the sense that the line with the duplicate date sometimes appears before the other line. As an aside, the manual page states -reopen (Windows NT and later only) Reopen the log file of the running NT Service but this report is for a Linux machine. Am I confusing what the manual page states for a command line option with the fact that stunnel reopens the log file periodicaly on all platforms? In addition to my possible misunderstanding about the log file being reopened, I find it odd there is a log file mentioned at all. Because I didn't configured a log file in the configuration file at all. Returning to the duplicate lines issue, I have tried to run stunnel directly from the command line, as in # /usr/bin/stunnel /etc/stunnel/stunnel.conf & With this command line, I got log messages in the terminal, as well as in systemd journal. Can it be that when run by the systemd template, the lines from the terminal are directed to the journal, and that explain the duplication?

2 1

SSL handshake failure
by Jean-Luc Deschamps Berger 03 Mar '26

03 Mar '26

Hi, I have an issue with one connection using stunnel as client. The purpose is to connect to a server on port 8443. The connection works on the first request. But the second one is always rejected. In the log, I see on the second connection, an attempt to resume and then a handshake failure. I have tried some different parameters sslVersion, options... but with still the same issue. As there is no performance issue on this connection, is there any parameter that can stop the resume attempt ? See below the configuration file and traces of first request (Ok) and second request (NotOK). Thanks by advance for your help. Best regards Jean-Luc DESCHAMPS BERGER stunnel.conf ------------------------------------------------------ client = yes output = /GPTO/CCTMP/stunnel.log debug = 7 [olt] accept = localhost:8443 connect = 10.75.1.6:8443 verifyChain = no sslVersion = TLSv1.2 options = NO_SSLv2 options = NO_SSLv3 First connection: OK ------------------------------------------------------------------ 2026.03.04 02:00:02 LOG5[0]: Service [olt] accepted connection from 127.0.0.1:58704 2026.03.04 02:00:02 LOG6[0]: s_connect: connecting 10.75.1.6:8443 2026.03.04 02:00:02 LOG7[0]: s_connect: s_poll_wait 10.75.1.6:8443: waiting 10 seconds 2026.03.04 02:00:02 LOG7[0]: FD=6 events=0x2001 revents=0x0 2026.03.04 02:00:02 LOG7[0]: FD=15 events=0x2005 revents=0x0 2026.03.04 02:00:02 LOG5[0]: s_connect: connected 10.75.1.6:8443 2026.03.04 02:00:02 LOG5[0]: Service [olt] connected remote server from 192.168.16.249:42547 2026.03.04 02:00:02 LOG7[0]: Setting remote socket options (FD=15) 2026.03.04 02:00:02 LOG7[0]: Option TCP_NODELAY set on remote socket 2026.03.04 02:00:02 LOG7[0]: Remote descriptor (FD=15) initialized 2026.03.04 02:00:02 LOG6[0]: SNI: sending servername: 10.75.1.6 2026.03.04 02:00:02 LOG7[0]: No previous session to resume 2026.03.04 02:00:02 LOG6[0]: Peer certificate not required 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): before/connect initialization 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write client hello A 2026.03.04 02:00:02 LOG7[0]: OCSP stapling: Client callback called 2026.03.04 02:00:02 LOG6[0]: OCSP: Certificate chain verification disabled 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server hello A 2026.03.04 02:00:02 LOG6[0]: CERT: Certificate verification disabled 2026.03.04 02:00:02 LOG6[0]: CERT: Certificate verification disabled 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server certificate A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server key exchange A 2026.03.04 02:00:02 LOG6[0]: Client certificate not requested 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read server done A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write client key exchange A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write change cipher spec A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 write finished A 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 flush data 2026.03.04 02:00:02 LOG7[0]: TLS state (connect): SSLv3 read finished A 2026.03.04 02:00:02 LOG7[0]: New session callback 2026.03.04 02:00:02 LOG7[0]: Peer certificate was cached (1241 bytes) 2026.03.04 02:00:02 LOG6[0]: Session id: A8CFAD0D0E7D060D56EFF5045F8E1570727951423AB00D7CF70B4E4423396293 2026.03.04 02:00:02 LOG7[0]: 1 client connect(s) requested 2026.03.04 02:00:02 LOG7[0]: 1 client connect(s) succeeded 2026.03.04 02:00:02 LOG7[0]: 0 client renegotiation(s) requested 2026.03.04 02:00:02 LOG7[0]: 0 session reuse(s) 2026.03.04 02:00:02 LOG6[0]: TLS connected: new session negotiated 2026.03.04 02:00:02 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) 2026.03.04 02:00:02 LOG7[0]: Compression: null, expansion: null 2026.03.04 02:00:02 LOG6[0]: Read socket closed (readsocket) 2026.03.04 02:00:02 LOG7[0]: Sending close_notify alert 2026.03.04 02:00:02 LOG7[0]: TLS alert (write): warning: close notify 2026.03.04 02:00:02 LOG6[0]: SSL_shutdown successfully sent close_notify alert 2026.03.04 02:00:02 LOG6[0]: transfer: SSL_read: Socket is closed 2026.03.04 02:00:02 LOG6[0]: TLS socket closed (SSL_read) 2026.03.04 02:00:02 LOG7[0]: Sent socket write shutdown 2026.03.04 02:00:02 LOG5[0]: Connection closed: 593 byte(s) sent to TLS, 704 byte(s) sent to socket Second connection: notOK ------------------------------------------------------------------------------------------------------------- 2026.03.04 02:00:04 LOG5[1]: Service [olt] accepted connection from 127.0.0.1:58710 2026.03.04 02:00:04 LOG6[1]: s_connect: connecting 10.75.1.6:8443 2026.03.04 02:00:04 LOG7[1]: s_connect: s_poll_wait 10.75.1.6:8443: waiting 10 seconds 2026.03.04 02:00:04 LOG7[1]: FD=6 events=0x2001 revents=0x0 2026.03.04 02:00:04 LOG7[1]: FD=15 events=0x2005 revents=0x0 2026.03.04 02:00:04 LOG5[1]: s_connect: connected 10.75.1.6:8443 2026.03.04 02:00:04 LOG5[1]: Service [olt] connected remote server from 192.168.16.249:42553 2026.03.04 02:00:04 LOG7[1]: Setting remote socket options (FD=15) 2026.03.04 02:00:04 LOG7[1]: Option TCP_NODELAY set on remote socket 2026.03.04 02:00:04 LOG7[1]: Remote descriptor (FD=15) initialized 2026.03.04 02:00:04 LOG6[1]: SNI: sending servername: 10.75.1.6 2026.03.04 02:00:04 LOG6[1]: Attempting to resume: A8CFAD0D0E7D060D56EFF5045F8E1570727951423AB00D7CF70B4E4423396293 2026.03.04 02:00:04 LOG6[1]: Peer certificate not required 2026.03.04 02:00:04 LOG7[1]: TLS state (connect): before/connect initialization 2026.03.04 02:00:04 LOG7[1]: TLS state (connect): SSLv3 write client hello A 2026.03.04 02:00:04 LOG7[1]: TLS alert (read): fatal: handshake failure 2026.03.04 02:00:04 LOG3[1]: SSL_connect: s3_pkt.c:1259: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure: client 127.0.0.1:58710 2026.03.04 02:00:04 LOG5[1]: Connection closed/reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2026.03.04 02:00:04 LOG7[1]: Remote descriptor (FD=15) closed 2026.03.04 02:00:04 LOG7[1]: local_rfd/local_wfd reset (FD=3) 2026.03.04 02:00:04 LOG7[1]: Local descriptor (FD=3) closed 2026.03.04 02:00:04 LOG7[1]: Service [olt] finished (0 left)

1 0

How to use static DH parameters?
by Ian Pilcher 28 Feb '26

28 Feb '26

I am trying to configure stunnel to use static DH parameters. The man page says: Alternatively, it is possible to specify static DH parameters in the certificate file, which disables generating temporary DH parameters: openssl dhparam 2048 >> stunnel.pem But, I'm not 100% clear on what certificate file it is talking about. My configuration looks like this. [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 Would I add the DH parameters to /etc/pki/tls/certs/stunnel/switch2.crt? Thanks! -- ======================================================================== If your user interface is intuitive in retrospect ... it isn't intuitive ========================================================================

2 1

List server change
by Michał Trojnara 28 Feb '26

28 Feb '26

Dear users, The list address has been changed from stunnel-users(a)stunnel.org to stunnel-users(a)lists.stunnel.org. Please let me know if you experience any issues caused by this change. Best regards, Mike

1 0

Fwd: timegm not supported in AIX
by shubham gupta 26 Feb '26

26 Feb '26

Hi, Sorry for the wrong patch. I have attached the corrected one in this email. Thanks, Shubham ---------- Forwarded message --------- From: shubham gupta <shubham17031994(a)gmail.com> Date: Thu, Feb 26, 2026 at 2:55 PM Subject: timegm not supported in AIX To: <stunnel-users(a)stunnel.org> Hi, I am building the latest stunnel on an AIX machine. However I see build failure due to missing API timegm. Snippet from the error generating file src/oscp.c #ifdef _WIN32 return _mkgmtime(&tm); #else /* defined _WIN32 */ return timegm(&tm); #endif /* defined _WIN32 */ Error log: libtool: link: /opt/freeware/bin/gcc -maix64 -O2 -DOPENSSL_NO_PSK -g -O2 -Wall -Wextra -Wpedantic -Wformat=2 -Wconversion -Wno-deprecated-declarations -Wno-unused-command-line-argument -fPIE -D_FORTIFY_SOURCE=2 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -fPIE -pie -o stunnel stunnel-tls.o stunnel-str.o stunnel-file.o stunnel-client.o stunnel-log.o stunnel-options.o stunnel-protocol.o stunnel-network.o stunnel-resolver.o stunnel-ssl.o stunnel-ctx.o stunnel-verify.o stunnel-sthreads.o stunnel-ocsp.o stunnel-fd.o stunnel-dhparam.o stunnel-cron.o stunnel-stunnel.o stunnel-pty.o stunnel-libwrap.o stunnel-ui_unix.o -L/usr/lib -lssl -lcrypto -L/opt/freeware/lib64 -L/opt/freeware/lib -lpthread ld: 0711-317 ERROR: Undefined symbol: .timegm Please consider the patch attached along with the email for fixing the issue. Thanks, Shubham [image: Mailsuite] Email tracked with Mailsuite · Opt out <https://u.list-prefs.com/en/privacy/opt-out/unsubscribe/906ba64869a1f2284b6…> 26/02/26, 14:51:51

2 2

systemd and stunnel.service
by Mike 25 Feb '26

25 Feb '26

I'm setting up a new ubuntu server and it includes stunnel version 5.74. My ultimate goal is to have the service managed by systemd. Things didn't really work out of the box because of the needed configuration file which I was able to use from an existing didn't have the appropriate information in it. So, even though it would start (using initd), when I would try to stop it, it wouldn't. This turned out to be pretty straightforward solve by adding the following to my one and only conf file: setuid = stunnel4 setgid = stunnel4 ; PID file is created inside the chroot jail (if enabled) pid = /var/run/stunnel4/stunnel4.pid While the example file in /usr/share/doc/stunnel4/examples/stunnel.conf-sample had these entries in the file, they were commented out and I wasn't sure if that those were actual defaults, or needed to be uncommented for production. The later seemed to be the case. After fixing that, I was able to use systemctl start/stop as normal, however I noticed that it was being started by the old initd setup. #system status stunnel4 ● stunnel4.service - LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons) Loaded: loaded (/etc/init.d/stunnel4; generated) Active: active (running) since Tue 2026-02-24 20:35:35 CST; 2s ago Invocation: 343fad33bfb949aa8b48285e37c7f05a Docs: man:systemd-sysv-generator(8) Process: 4754 ExecStart=/etc/init.d/stunnel4 start (code=exited, status=0/SUCCESS) Tasks: 4 (limit: 4367) CPU: 192ms CGroup: /system.slice/stunnel4.service So after further searching I found the following files: /usr/lib/systemd/system/stunnel.target /usr/lib/systemd/system/stunnel@.service I executed the command: systemctl enable stunnel@myconffile When I use this command: systemctl start stunnel@myconffile It definitely executes the correct command, but then the whole service shuts down and I get this: ○ stunnel(a)myconffile.service - TLS tunnel for network daemons - per-config-file service Loaded: loaded (/etc/systemd/system/stunnel@.service; enabled; preset: enabled) Active: inactive (dead) since Tue 2026-02-24 20:44:54 CST; 11s ago Duration: 20.157s Invocation: 46cddb34062b401b87e8516f47b1482b Docs: man:stunnel4(8) Process: 5099 ExecStart=/usr/bin/stunnel4 /etc/stunnel/attuverse.conf (code=exited, status=0/SUCCESS) Main PID: 5099 (code=exited, status=0/SUCCESS) CPU: 128ms No stunnel service is running. There wasn't anything in the log that I could find that would indicate why it stopped. if I execute this command: /usr/bin/stunnel4 /etc/stunnel/myconffile.conf It works how I would expect it to. For now I'm using the initd initialization, but I would love to get the systemd version running. Anyone have some suggestions? Thanks. Mike

4 13