stunnel-users

Download

[email protected]

July 2026

1 participants
2 discussions

[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

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