[stunnel-users] stunnel-users Digest, Vol 182, Issue 14

[Eric Eberhard]

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 at stunnel.org] On Behalf Of Brent Kimberley
Sent: Friday, September 27, 2019 7:29 AM
To: stunnel-users at stunnel.org; andrew.lynch at 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 at atos.net <mailto:andrew.lynch at atos.net> >

To: Eric Eberhard <flash at vicsmba.com <mailto:flash at vicsmba.com> >

Cc: "stunnel-users at stunnel.org <mailto:stunnel-users at stunnel.org> " <stunnel-users at stunnel.org <mailto:stunnel-users at 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 at vicsmba.com <mailto:flash at vicsmba.com> ] 

Sent: Thursday, September 26, 2019 7:20 PM

To: Lynch, Andrew; stunnel-users at stunnel.org <mailto:stunnel-users at 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 at stunnel.org <mailto:stunnel-users-bounces at stunnel.org> ] On Behalf Of Lynch, Andrew

Sent: Thursday, September 26, 2019 5:56 AM

To: stunnel-users at stunnel.org <mailto:stunnel-users at 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 at stunnel.org <mailto:stunnel-users at stunnel.org> 

https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

 

 

 

 

------------------------------

 

Subject: Digest Footer

 

_______________________________________________

stunnel-users mailing list

stunnel-users at stunnel.org <mailto:stunnel-users at stunnel.org> 

https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

 

 

------------------------------

 

End of stunnel-users Digest, Vol 182, Issue 14

**********************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20190927/bb622f91/attachment.htm>