stunnel-users September 2019

stunnel-users@stunnel.org

12 participants
23 discussions

Requests to cloud server that requires host header
by Lorne Kates 13 Nov '24

13 Nov '24

(related to Akamai message from before-- but I have better troubleshooting information). I'm tying to route traffic through stunnel to a "cloud" based-endpoint. That endpoint has a static server name-- test.authorize.net. (This is the dev sandbox for auth.net). But if you do an nslookup on test.authorize.net, you'll get back a different servername and IP, because it's so wonderfully "cloud". Stunnel apparently tries to connect to the nslookup value. The server rejects the request because it can't route it back to test.authorize.net. I've tried adding "delay = yes" and "sni = test.authorize.net", but neither work. To see this in action, a simple setup with any accept, then connect to test.authorize.net:443 in client = yes mode. This is what a valid response looks like (13 -- give me the darn merchant ID in a POST): https://test.authorize.net/gateway/transact.dll This is what you'll get if you try to use stunnel (400 invalid url) : https://23.195.204.150/gateway/transact.dll So how can I get stunnel to send the proper Request Header (host: test.authorize.net), make sure it's using http/1.1, etc?

4 3

Re: [stunnel-users] CPU 100%
by Eric Eberhard 06 Nov '24

06 Nov '24

Long ago I had a server with a bad network card. Every once in a while it would spew uncontrollable bytes onto the network. If you open a stunnel connection and it does that this could very well be the problem. If it cheap, try changing the network card. If not, you should be able to look in your firewall/router and it will tell you who is sending what bytes to whomever. See if that machine is indeed streaming the bytes in massive quantities. If not, I would suspect your stunnel is getting stuck in it's own loop. There are a million reasons this can happen (well a few less than a million) - such as maybe a bad library in the FreeBSD or a bad choice in the Makefile - such as doing threads or something in a way your O/S does not like (I use threads=fork or whatever it is, instead of actual threading). You might tinker with some of the options that make the stunnel build and try different ones. Especially if stunnel was compiled on a different version of the O/S - could be differences in bytes in things and who knows what. That is all I can suggest beyond setting the debug level to 7 (I think is highest) and then watching the log file. Eric From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Murrey, Brian J. Sent: Wednesday, October 17, 2018 10:57 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] CPU 100% We are running stunnel 5.49 on FreeBSD 11.2 and we're running into a problem once in a while. CPU pegs at 100% when we get an stunnel connection from one of our external devices. This affects 100% of all cores and we can't even log in to console. To mitigate this temporarily, we have a script running in the background to watch when stunnel begins to spike and restarts the daemon. It doesn't happen 100% of the time, and so far I have been unable to distinguish what makes the connection do this to the CPU. Have any of you run in to this issue? Sincerely, Brian Murrey System Engineer II, IT Infrastructure _____ NOTICE: This message may contain privileged and confidential information and/or protected health information intended solely for the use of the named recipient and may be privileged or otherwise protected by law. If you are not the intended recipient of this message, you should immediately notify the sender and delete this message. Do not disseminate, reproduce, or review this message or attachments if you are not the intended recipient. The sender or others may have legal rights restricting the dissemination of the information contained in this message and, as a result, remedies against you in the event of the improper dissemination of confidential information, trade secrets, personal information or privileged communications. This message is the work of the sender and does not necessarily reflect the position, views, or policies of TriMedx LLC or its affiliates. WARNING: The integrity and security of this message cannot be guaranteed and may contain or transmit a virus or other illicit code. Neither TriMedx LLC or its affiliates accept liability for any damage attributable to viruses or illicit code transmitted through this message or an attachment.

2 1

older browsers, stunnel and privoxy
by kovacs janos 04 Mar '24

04 Mar '24

sorry to bother, im trying to make older browsers be able to display TLS 1.1 and TLS 1.2 sites. i heard stunnel cant be configured to always forward to the current site address dynamically, thats why i would use privoxy. the browser is configured to send to: 127.0.0.1 443 stunnel config has this at the end: [Tunnel_in] client = yes accept = 127.0.0.1:443 connect = 127.0.0.1:8118 verifyChain = yes CAfile = ca-certs.pem checkHost = localhost 127.0.0.1:8118 is the privoxy address. this is what stunnel writes: LOG5[main]: Configuration successful LOG5[0]: Service [Tunnel_in] accepted connection from 127.0.0.1:3261 LOG5[0]: s_connect: connected 127.0.0.1:8118 LOG5[0]: Service [Tunnel_in] connected remote server from 127.0.0.1:3262 and the browser infinitely loads, and never loads anything or leaves the page. if i remove the last 3 lines, its the same just with this line added: LOG4[main]: Service [Tunnel_in] needs authentication to prevent MITM attacks but it doesnt give an error or anything. with a configuration like: [Tunnel_out] client = no accept = 127.0.0.1:443 connect = 127.0.0.1:8118 cert = stunnel.pem this is what it gives: LOG5[3]: Service [Tunnel_out] accepted connection from 127.0.0.1:3294 LOG3[3]: SSL_accept: 1407609B: error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request LOG5[3]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket and browser gives a server not found error immediately. im not even sure if i should use client or server configuration in a case like this, but none of them works anyway. all i would need is for my browser to get the pages decrypted, or at least in less than TLS1.1. like how on newipnow.com i can access sites with any encryption, since they are sent to the browser without encryption. the browser just gives an "unencrypted tunnel" warning, which is how i found stunnel, and which is exactly what i need, just locally.

8 41

Stunnel 4 failing to connect to gmail
by Asif Iqbal 11 Dec '20

11 Dec '20

I am faling to connect to gmail. Not sure what that bind error means. iqbala@ghar:~$ sudo stunnel4 2008.12.15 13:53:17 LOG7[3839:3083650736]: Snagged 64 random bytes from /home/iqbala/.rnd 2008.12.15 13:53:17 LOG7[3839:3083650736]: Wrote 1024 new random bytes to /home/iqbala/.rnd 2008.12.15 13:53:17 LOG7[3839:3083650736]: RAND_status claims sufficient entropy for the PRNG 2008.12.15 13:53:17 LOG7[3839:3083650736]: PRNG seeded successfully 2008.12.15 13:53:17 LOG7[3839:3083650736]: Certificate: /etc/stunnel/stunnel.pem 2008.12.15 13:53:17 LOG7[3839:3083650736]: Certificate loaded 2008.12.15 13:53:17 LOG7[3839:3083650736]: Key file: /etc/stunnel/stunnel.pem 2008.12.15 13:53:17 LOG7[3839:3083650736]: Private key loaded 2008.12.15 13:53:17 LOG7[3839:3083650736]: SSL context initialized for service ssmtp 2008.12.15 13:53:17 LOG5[3839:3083650736]: stunnel 4.22 on i486-pc-linux-gnu with OpenSSL 0.9.8g 19 Oct 2007 2008.12.15 13:53:17 LOG5[3839:3083650736]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP 2008.12.15 13:53:17 LOG6[3839:3083650736]: file ulimit = 1024 (can be changed with 'ulimit -n') 2008.12.15 13:53:17 LOG6[3839:3083650736]: poll() used - no FD_SETSIZE limit for file descriptors 2008.12.15 13:53:17 LOG5[3839:3083650736]: 500 clients allowed 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 10 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 11 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 12 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: SO_REUSEADDR option set on accept socket 2008.12.15 13:53:17 LOG3[3839:3083650736]: Error binding ssmtp to 74.125.93.111:587 2008.12.15 13:53:17 LOG3[3839:3083650736]: bind: Cannot assign requested address (99) Here is how my conf file looks like iqbala@ghar:~$ cat /etc/stunnel/stunnel.conf | egrep -v "^;|^$" cert = /etc/stunnel/stunnel.pem foreground = yes sslVersion = SSLv3 chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 pid = /stunnel4.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 output = /var/log/stunnel4/stunnel.log client = yes [ssmtp] accept = smtp.gmail.com:587 connect = 25 Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu

5 9

Stunnel & Gmail security
by BOXI31 TEST 17 Oct '20

17 Oct '20

Hi all, To make "Stunnel 5.31" work with Gmail, I have to go in security settings of Gmail and "allow less secure apps to access my account". Is it mandatory ? Is it possible to set Stunnel to access Gmail without lowering it security level ? How ? I checked in log file TLS v1.2 is used by Stunnel but Gmail still consider it as a "less secure app." ! Regards, Steve

2 1

segfault with v5.55
by Mark Brookes 30 Sep '19

30 Sep '19

We are currently experiencing a segfault with version 5.55 openssl version 1.1.0k and are trying to narrow down what the issue may be. The first 2 segfaults are about 10 mins apart. The below is from the stunnel log just before and then after the event. Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77582]: TLS state (accept): SSLv3/TLS write finished Sep 23 11:47:31 xxxx stunnel: LOG7[77582]: TLS state (accept): SSLv3/TLS read change cipher spec Sep 23 11:47:31 xxxx stunnel: LOG7[77582]: TLS state (accept): SSLv3/TLS read finished Sep 23 11:47:31 xxxx stunnel: LOG7[77580]: TLS state (accept): SSLv3/TLS write finished Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Deallocating application specific data for session connect address Sep 23 11:47:31 xxxx stunnel: LOG7[77581]: Remove session callback Sep 23 11:52:58 xxxx stunnel: LOG7[ui]: Clients allowed=62937 Sep 23 11:52:58 xxxx stunnel: LOG5[ui]: stunnel 5.55 on x86_64-pc-linux-gnu platform Sep 23 11:52:58 xxxx stunnel: LOG5[ui]: Compiled/running with OpenSSL 1.1.0k 28 May 2019 Sep 23 11:52:58 xxxx stunnel: LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,OCSP,PSK,SNI Sep 23 11:52:58 xxxx stunnel: LOG7[ui]: errno: (*__errno_location ()) The following is from the kernel log. stunnel[31253]: segfault at 0 ip 00007f91214cacea sp 00007f91205ea9f8 error 6 in libpthread-2.12.so[7f91214c0000+17000] The kernel log after the second segfault- stunnel[1868]: segfault at 0 ip 00007f5b35398cea sp 00007f5b344c59f8 error 6 in libpthread-2.12.so[7f5b3538e000+17000] This is all the information we have at the moment. -- Mark Brookes Loadbalancer.org Ltd. www.loadbalancer.org +44 (0)330 380 1064 mark(a)loadbalancer.org

1 0

Re: [stunnel-users] stunnel with OpenSSL engine: reload leaks HSM connections
by Lynch, Andrew 27 Sep '19

27 Sep '19

I’ve been digging around the code and I am no longer sure whether stunnel is at fault or it is actually an issue in OpenSSL! load_key_engine() in ctx.c shoves the key into the SSL context – SSL_CTX_use_PrivateKey(section->ctx, pkey). So the key should be freed when that context is disposed of. The SIGHUP ends up in case SIGNAL_RELOAD_CONFIG of signal_pipe_dispatch(), which calls options_free() [stunnel.c line 830]. Eventually there is an SSL_CTX_free() call, but it looks like this does not actually free the private key. Ephemeral keys are freed and loads of other stuff, but not the private key associated with the certificate. I may try to build a hacked OpenSSL on Monday to see what happens if SSL_CTX_free also frees the private key… Regards, Andrew. From: Brent Kimberley [mailto:brent_kimberley@rogers.com] Sent: Friday, September 27, 2019 4:29 PM To: stunnel-users(a)stunnel.org; Lynch, Andrew Subject: Re: 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:andrew.lynch@atos.net>> To: Eric Eberhard <flash(a)vicsmba.com<mailto:flash@vicsmba.com>> Cc: "stunnel-users(a)stunnel.org<mailto:stunnel-users@stunnel.org>" <stunnel-users(a)stunnel.org<mailto:stunnel-users@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:flash@vicsmba.com<mailto:flash@vicsmba.com>] Sent: Thursday, September 26, 2019 7:20 PM To: Lynch, Andrew; stunnel-users(a)stunnel.org<mailto:stunnel-users@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:stunnel-users-bounces@stunnel.org<mailto:stunnel-users-bounces@stunnel.org>] On Behalf Of Lynch, Andrew Sent: Thursday, September 26, 2019 5:56 AM To: stunnel-users(a)stunnel.org<mailto:stunnel-users@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<mailto:stunnel-users@stunnel.org> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users ------------------------------ Subject: Digest Footer _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org<mailto:stunnel-users@stunnel.org> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users ------------------------------ End of stunnel-users Digest, Vol 182, Issue 14 **********************************************

2 1

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:stunnel-users-bounces@stunnel.org] 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:andrew.lynch@atos.net> > To: Eric Eberhard <flash(a)vicsmba.com <mailto:flash@vicsmba.com> > Cc: "stunnel-users(a)stunnel.org <mailto:stunnel-users@stunnel.org> " <stunnel-users(a)stunnel.org <mailto:stunnel-users@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:flash@vicsmba.com <mailto:flash@vicsmba.com> ] Sent: Thursday, September 26, 2019 7:20 PM To: Lynch, Andrew; stunnel-users(a)stunnel.org <mailto:stunnel-users@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:stunnel-users-bounces@stunnel.org <mailto:stunnel-users-bounces@stunnel.org> ] On Behalf Of Lynch, Andrew Sent: Thursday, September 26, 2019 5:56 AM To: stunnel-users(a)stunnel.org <mailto:stunnel-users@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 <mailto:stunnel-users@stunnel.org> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users ------------------------------ Subject: Digest Footer _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org <mailto:stunnel-users@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-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:flash@vicsmba.com] 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:stunnel-users-bounces@stunnel.org] 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:stunnel-users-bounces@stunnel.org] 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users September 2019