June 2026 - stunnel-users

[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.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