stunnel-users

3306 discussions

Re: [stunnel-users] stunnel-users Digest, Vol 182, Issue 14
by Eric Eberhard 27 Sep '19

27 Sep '19

I don’t suggest it as a final solution – although for me it works great and we have customers exchanging 2-4 million XML documents per day with no performance issues – BUT no matter what it is a good debugging tool. Inetd gets all the initial connections and closes them when done. It might or might or might not be involved with the HSM at all. You might also look at the process table (some form of ps) and grep for stunnel and relatives and see if they are hanging around. In theory, if a process dies, it “should” close it’s connections. If it is floating in space it will not. Inetd will kill the process – at least on Centos and AIX and SCO – for sure and for certain. E From: stunnel-users [mailto:[email protected]] On Behalf Of Brent Kimberley Sent: Friday, September 27, 2019 7:29 AM To: stunnel-users(a)stunnel.org; andrew.lynch(a)atos.net Subject: Re: [stunnel-users] stunnel-users Digest, Vol 182, Issue 14 >> Over time, after numerous reloads of stunnel (kill -HUP) the HSM reports that its connection table is full. >> Logging from the engine shows that stunnel is never freeing the keys and therefore the engine is not closing the associated sessions with the HSM. Each stunnel reload opens 70 new sessions until eventually the HSM's configured limit is exceeded. Where does the signal dispatcher free keys on SIG_HUP? https://github.com/mtrojnar/stunnel/blob/master/src/stunnel.c Date: Fri, 27 Sep 2019 07:23:29 +0000 From: "Lynch, Andrew" <andrew.lynch(a)atos.net <mailto:[email protected]> > To: Eric Eberhard <flash(a)vicsmba.com <mailto:[email protected]> > Cc: "stunnel-users(a)stunnel.org <mailto:[email protected]> " <stunnel-users(a)stunnel.org <mailto:[email protected]> > Subject: Re: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections Hi Eric, Thank you for your suggestion. It is certainly worth looking into, although I suspect it may be impractical in our environment. Now we have a single stunnel.conf with 70 services which would translate into 70 additional entries in inetd.conf. Each of those entries then needs to have its own reduced stunnel.conf so that it will only load the cert and key for its endpoint. The stunnel HOWTO recommends daemon mode over inetd mode due to the overhead for forking and SSL initialization. We would have additional overhead for engine init and HSM connection. Regards, Andrew. -----Original Message----- From: Eric Eberhard [mailto:[email protected] <mailto:[email protected]> ] Sent: Thursday, September 26, 2019 7:20 PM To: Lynch, Andrew; stunnel-users(a)stunnel.org <mailto:[email protected]> Subject: RE: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections? Try running in inetd mode -- even if you don't like this you will learn something. Inetd will close connections as needed. E -----Original Message----- From: stunnel-users [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Lynch, Andrew Sent: Thursday, September 26, 2019 5:56 AM To: stunnel-users(a)stunnel.org <mailto:[email protected]> Subject: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections? Hi, We are using stunnel as a server to terminate incoming TLS connections. The config has around 70 services with certificates whose EC private keys are stored in an HSM and accessed using an OpenSSL engine. Over time, after numerous reloads of stunnel (kill -HUP) the HSM reports that its connection table is full. Logging from the engine shows that stunnel is never freeing the keys and therefore the engine is not closing the associated sessions with the HSM. Each stunnel reload opens 70 new sessions until eventually the HSM's configured limit is exceeded. This behaviour has been observed on Suse Enterprise Linux 12.3 with the system-provided stunnel-5.00-4.3.4, but I can reproduce it with my own build of the current version 5.55. Is this a known issue? It appears that other (ephemeral) keys are being freed, just not those associated with the service certificates. Currently our workaround is to perform a full restart instead of a reload. This closes all HSM sessions when the process terminates, but of course it also kills any open client connections so it can only be done during the scheduled maintenance windows. Regards, Andrew. _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org <mailto:[email protected]> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users ------------------------------ Subject: Digest Footer _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org <mailto:[email protected]> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users ------------------------------ End of stunnel-users Digest, Vol 182, Issue 14 **********************************************

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 182, Issue 14
by Brent Kimberley 27 Sep '19

27 Sep '19

>> Over time, after numerous reloads of stunnel (kill -HUP) the HSM reports that its connection table is full. >> Logging from the engine shows that stunnel is never freeing the keys and therefore the engine is not closing the associated sessions with the HSM. Each stunnel reload opens 70 new sessions until eventually the HSM's configured limit is exceeded. Where does the signal dispatcher free keys on SIG_HUP?https://github.com/mtrojnar/stunnel/blob/master/src/stunnel.c Date: Fri, 27 Sep 2019 07:23:29 +0000 From: "Lynch, Andrew" <andrew.lynch(a)atos.net> To: Eric Eberhard <flash(a)vicsmba.com> Cc: "stunnel-users(a)stunnel.org" <stunnel-users(a)stunnel.org> Subject: Re: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections Hi Eric, Thank you for your suggestion. It is certainly worth looking into, although I suspect it may be impractical in our environment. Now we have a single stunnel.conf with 70 services which would translate into 70 additional entries in inetd.conf. Each of those entries then needs to have its own reduced stunnel.conf so that it will only load the cert and key for its endpoint. The stunnel HOWTO recommends daemon mode over inetd mode due to the overhead for forking and SSL initialization. We would have additional overhead for engine init and HSM connection. Regards, Andrew. -----Original Message----- From: Eric Eberhard [mailto:[email protected]] Sent: Thursday, September 26, 2019 7:20 PM To: Lynch, Andrew; stunnel-users(a)stunnel.org Subject: RE: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections? Try running in inetd mode -- even if you don't like this you will learn something. Inetd will close connections as needed. E -----Original Message----- From: stunnel-users [mailto:[email protected]] On Behalf Of Lynch, Andrew Sent: Thursday, September 26, 2019 5:56 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections? Hi, We are using stunnel as a server to terminate incoming TLS connections. The config has around 70 services with certificates whose EC private keys are stored in an HSM and accessed using an OpenSSL engine. Over time, after numerous reloads of stunnel (kill -HUP) the HSM reports that its connection table is full. Logging from the engine shows that stunnel is never freeing the keys and therefore the engine is not closing the associated sessions with the HSM. Each stunnel reload opens 70 new sessions until eventually the HSM's configured limit is exceeded. This behaviour has been observed on Suse Enterprise Linux 12.3 with the system-provided stunnel-5.00-4.3.4, but I can reproduce it with my own build of the current version 5.55. Is this a known issue? It appears that other (ephemeral) keys are being freed, just not those associated with the service certificates. Currently our workaround is to perform a full restart instead of a reload. This closes all HSM sessions when the process terminates, but of course it also kills any open client connections so it can only be done during the scheduled maintenance windows. Regards, Andrew. _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users ------------------------------ Subject: Digest Footer _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users ------------------------------ End of stunnel-users Digest, Vol 182, Issue 14 **********************************************

1 0

Re: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections?
by Eric Eberhard 27 Sep '19

27 Sep '19

Try running in inetd mode -- even if you don't like this you will learn something. Inetd will close connections as needed. E -----Original Message----- From: stunnel-users [mailto:[email protected]] On Behalf Of Lynch, Andrew Sent: Thursday, September 26, 2019 5:56 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections? Hi, We are using stunnel as a server to terminate incoming TLS connections. The config has around 70 services with certificates whose EC private keys are stored in an HSM and accessed using an OpenSSL engine. Over time, after numerous reloads of stunnel (kill -HUP) the HSM reports that its connection table is full. Logging from the engine shows that stunnel is never freeing the keys and therefore the engine is not closing the associated sessions with the HSM. Each stunnel reload opens 70 new sessions until eventually the HSM's configured limit is exceeded. This behaviour has been observed on Suse Enterprise Linux 12.3 with the system-provided stunnel-5.00-4.3.4, but I can reproduce it with my own build of the current version 5.55. Is this a known issue? It appears that other (ephemeral) keys are being freed, just not those associated with the service certificates. Currently our workaround is to perform a full restart instead of a reload. This closes all HSM sessions when the process terminates, but of course it also kills any open client connections so it can only be done during the scheduled maintenance windows. Regards, Andrew. _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

2 1

stunnel with OpenSSL engine: reload leaks HSM connections?
by Lynch, Andrew 26 Sep '19

26 Sep '19

Hi, We are using stunnel as a server to terminate incoming TLS connections. The config has around 70 services with certificates whose EC private keys are stored in an HSM and accessed using an OpenSSL engine. Over time, after numerous reloads of stunnel (kill -HUP) the HSM reports that its connection table is full. Logging from the engine shows that stunnel is never freeing the keys and therefore the engine is not closing the associated sessions with the HSM. Each stunnel reload opens 70 new sessions until eventually the HSM's configured limit is exceeded. This behaviour has been observed on Suse Enterprise Linux 12.3 with the system-provided stunnel-5.00-4.3.4, but I can reproduce it with my own build of the current version 5.55. Is this a known issue? It appears that other (ephemeral) keys are being freed, just not those associated with the service certificates. Currently our workaround is to perform a full restart instead of a reload. This closes all HSM sessions when the process terminates, but of course it also kills any open client connections so it can only be done during the scheduled maintenance windows. Regards, Andrew.

1 0

Re: [stunnel-users] Problems when using PSK between a version of stunnel usingopenssl 1.0 and a version of stunnel using openssl 1.1.1 in stunnel-users Digest, Vol 182, Issue 7
by Koperberg, J. (Hannah) 25 Sep '19

25 Sep '19

Hi Brent Thank you for your suggestions. I installed stunnel version 5.55 on the client test side (where the openssl version OpenSSL 1.1.1c is). That has solved the problem. Kind regards and thanks again for your help, Hannah Koperberg, de Volksbank N.V., The Netherlands From: Brent Kimberley <brent_kimberley(a)rogers.com> Sent: woensdag 18 september 2019 18:30 To: stunnel-users(a)stunnel.org Subject: Re: [stunnel-users] stunnel-users Digest, Vol 182, Issue 7 psk_find() and psk_server_callback() are marked NOEXPORT. You can try whitebox - decompile ctx.c:: psk_server_callback() and/or blackbox - breaking the problem into parts to see what works/fails. Decomposing the problem into parts : a) Two differing stunnel versions and a common openssl library. b) One common stunnel version and two differing openssl libraries. On Wednesday, September 18, 2019, 11:28:48 a.m. EDT, Brent Kimberley <brent_kimberley(a)rogers.com<mailto:[email protected]>> wrote: >> 2019.09.16 13:36:28 LOG6[3]: PSK identity not found (session resumption?) Try dumping the symbols for ctx.c::psk_find(), ssl_lib.c::SSL_get_ex_data(), and ctx.c:: psk_server_callback(). ________________________________ Dit e-mailbericht is alleen bestemd voor de geadresseerden. Indien dit bericht niet voor u is bedoeld, wordt u verzocht de afzender hiervan op de hoogte te stellen door het bericht te retourneren en de inhoud niet te gebruiken. This e-mail message is intended to be exclusively for the addressee. If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message.

2 1

Re: [stunnel-users] stunnel-users Digest, Vol 182, Issue 11
by Brent Kimberley 24 Sep '19

24 Sep '19

>>We are running stunnel-5.49-1.ppc on AIX 7100-05-03-1846. >>It will stay up awhile and our connection tests work, but it core dumps. Here’s the message in the log file. Thoughts? >>INTERNAL ERROR: Out of memory at s3_both.c, line 626 Hi Gerald. You may have found a memory leak. Try looking at: 1) line 626 of OpenSSL::s3_booth.c https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_both.c 2) line 296 of stunnel::str.c ; and/or https://github.com/mtrojnar/stunnel/blob/stunnel-5.49/src/str.c 3) dbx, truss, or probevue - in an offline dev environment. http://archive.ibmsystemsmag.com/aix/administrator/performance/debugging-me…

1 0

AIX:stunnel core dumping
by Gerald Shaw 24 Sep '19

24 Sep '19

Hello, We are running stunnel-5.49-1.ppc on AIX 7100-05-03-1846. It will stay up awhile and our connection tests work, but it core dumps. Here’s the message in the log file. Thoughts? INTERNAL ERROR: Out of memory at s3_both.c, line 626 Best, Gerald Shaw

1 0

Cannot create .crt file
by John Khoo 24 Sep '19

24 Sep '19

Hi, I am new to STunnel. I come to know STunnel thru this link: http://www.ibphoenix.com/downloads/Secure_connections_to_Firebird_with_Stun… Based on the instruction, I tried create a certificate using this line below: openssl ca -config "C:\Program Files (x86)\stunnel\config\openssl.conf" -policy policy_anything -notext -in C:\CA\temp\vnc_server\server.req -out C:\CA\temp\vnc_server\server.crt However, no crt file is created and no error is prompted. I hope that someone can help me. Thanks.

1 0

Stunnel and Sophos UTM
by James Brown 20 Sep '19

20 Sep '19

Has anybody been able to use stunnel to update the Sophos UTM’s firewall? I know it has a Restful API , but do not know how to use this with stunnel. https://www.sophos.com/en-us/medialibrary/PDFs/documentation/UTMonAWS/Sopho… <https://www.sophos.com/en-us/medialibrary/PDFs/documentation/UTMonAWS/Sopho…> Any experiences or suggestions? Thanks, James.

2 1

Re: [stunnel-users] Stunnel help and guidance request
by Noonan, M.P. (Mike) 19 Sep '19

19 Sep '19

Hi Gerald, I assume you got stunnel from the oss4aix.org site. We don't use the freeware openssl, but instead the IBM one: [root@duist:/data/O01] lslpp -l | grep openssl openssl.base 1.0.2.1801 COMMITTED Open Secure Socket Layer openssl.license 1.0.2.1801 COMMITTED Open Secure Socket License openssl.man.en_US 1.0.2.1801 COMMITTED Open Secure Socket Layer openssl.base 1.0.2.1801 COMMITTED Open Secure Socket Layer I installed stunnel-5.29 on one of our lpars which I forced with -nodeps: rpm -Uhv --nodeps stunnel-5.29-1.aix5.2.ppc.rpm It picked up the IBM libs, but had the same problem... [root@duist:/data/O01] ldd /usr/bin/stunnel /usr/bin/stunnel needs: /usr/lib/threads/libc.a(shr.o) /usr/lib/libpthreads.a(shr_comm.o) /usr/lib/libpthreads.a(shr_xpg5.o) /usr/lib/libcrypto.a(libcrypto.so.1.0.2) /usr/lib/libssl.a(libssl.so.1.0.2) /unix /usr/lib/libcrypt.a(shr.o) [root@duist:/data/O01] /usr/bin/stunnel Could not load program /usr/bin/stunnel: Symbol resolution failed for stunnel because: Symbol strcmp (number 112) is not exported from dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.2). Symbol memmove (number 137) is not exported from dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.2). Symbol strncpy (number 142) is not exported from dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.2). Symbol strcpy (number 169) is not exported from dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.2). Symbol bcopy (number 245) is not exported from dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.2). I then downloaded and installed stunnel-5.49 from oss4aix.org and installed that version which worked fine.. [root@duist:/data/O01] /usr/bin/stunnel [ ] Clients allowed=31999 [.] stunnel 5.49 on powerpc-ibm-aix5.2.0.0 platform [.] Compiled with OpenSSL 1.0.2p 14 Aug 2018 [.] Running with OpenSSL 1.0.2r 26 Feb 2019 [.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI [ ] errno: (*_Errno()) [!] Invalid configuration file name "/opt/freeware/etc/stunnel/stunnel.conf" [!] realpath: No such file or directory (2) [ ] Deallocating section defaults I expect that if you upgrade your freeware openssl to at least 1,0,2r and upgrade stunnel to 5.49 your problem should be solved. Met vriendelijke groet, Mike Noonan From: stunnel-users <mailto:[email protected]> On Behalf Of Gerald Shaw Sent: Wednesday, September 18, 2019 11:18 PM To: mailto:[email protected] Subject: [stunnel-users] Stunnel help and guidance request Hello all, I'm new to the mailing list. I'm trying to run stunnel-5.29-1.ppc, and I'm having issues. I'd appreciate your help (or point me to the solution in the archives). OS - AIX 7100-05-03-1846 /home/shawg# rpm -qa|grep -i openssl openssl-1.0.2n-1.ppc /home/shawg# ldd `which stunnel` /usr/bin/stunnel needs: /usr/lib/libc.a(shr.o) /usr/lib/libpthreads.a(shr_comm.o) /usr/lib/libpthreads.a(shr_xpg5.o) /opt/freeware/lib/libcrypto.a(libcrypto.so.1.0.2) /opt/freeware/lib/libssl.a(libssl.so.1.0.2) /unix /usr/lib/libcrypt.a(shr.o) ** ERROR MESSAGE_- /home/shawg# /usr/bin/stunnel exec(): 0509-036 Cannot load program /usr/bin/stunnel because of the following errors: 0509-130 Symbol resolution failed for stunnel because: 0509-136 Symbol strcmp (number 112) is not exported from dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so.1.0.2). 0509-136 Symbol memmove (number 137) is not exported from dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so.1.0.2). 0509-136 Symbol strncpy (number 142) is not exported from dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so.1.0.2). 0509-136 Symbol strcpy (number 169) is not exported from dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so.1.0.2). 0509-136 Symbol bcopy (number 245) is not exported from dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so.1.0.2). 0509-192 Examine .loader section symbols with the 'dump -Tv' command. *** echo $LIBPATH /opt/freeware/lib:/usr/lib ________________________________ Dit e-mailbericht is alleen bestemd voor de geadresseerden. Indien dit bericht niet voor u is bedoeld, wordt u verzocht de afzender hiervan op de hoogte te stellen door het bericht te retourneren en de inhoud niet te gebruiken. This e-mail message is intended to be exclusively for the addressee. If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users