- stunnel-users - stunnel.org

report
by Danny Clowes 28 Dec '20

28 Dec '20

Hi, I'm using 5.7 stunnel for Debian. I have clients connecting to the server we are getting the following error message. I would be grateful if able to help? * Unable to use the beta version as the R-limit don't work and gives me error messages. Dec 28 08:44:33 debian stunnel: LOG4[129248]: Possible memory leak at ../ssl/packet_locl.h:385: 241533 allocations Dec 28 08:44:33 debian stunnel: LOG4[128031]: Possible memory leak at ../crypto/stack/stack.c:108: 243008 allocations Dec 28 08:44:33 debian stunnel: LOG4[129238]: Possible memory leak at ../crypto/stack/stack.c:108: 243008 allocations Dec 28 08:44:33 debian stunnel: LOG4[128031]: Possible memory leak at ../ssl/packet_locl.h:385: 241533 allocations Dec 28 08:44:33 debian stunnel: LOG4[129140]: Possible memory leak at ../crypto/stack/stack.c:108: 243008 allocations Dec 28 08:44:33 debian stunnel: LOG4[129140]: Possible memory leak at ../ssl/packet_locl.h:385: 241533 allocations Dec 28 08:44:33 debian stunnel: LOG4[129238]: Possible memory leak at ../ssl/packet_locl.h:385: 241533 allocations Dec 28 08:44:33 debian stunnel: LOG4[129206]: Possible memory leak at ../crypto/stack/stack.c:108: 243008 allocations Dec 28 08:44:33 debian stunnel: LOG4[129206]: Possible memory leak at ../ssl/packet_locl.h:385: 241533 allocations Dec 28 08:44:33 debian stunnel: LOG4[128166]: Possible memory leak at ../crypto/stack/stack.c:108: 243008 allocations Dec 28 08:44:33 debian stunnel: LOG4[128166]: Possible memory leak at ../ssl/packet_locl.h:385: 241533 allocations Thanks.

1 0

stunnel is stuck for 30 seconds
by dittyadler＠gmail.com 23 Dec '20

23 Dec '20

Hi, I'm running stunnel version 5.58 on Windows, everything works perfectly besides that sometimes stunnel gets stuck for 30 seconds - Nothing special in stunnel log, except for the 30 seconds delay: 2020.12.21 14:48:36 LOG6[8]: TLS connected: previous session reused 2020.12.21 14:48:36 LOG6[8]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2020.12.21 14:48:36 LOG6[8]: Peer temporary key: X25519, 253 bits 2020.12.21 14:48:36 LOG7[8]: Compression: null, expansion: null 2020.12.21 14:48:36 LOG6[8]: Session id: 8E62D0D8EB6359FEA7370E64AA7CC58EF9DB68059A5E01417E7038B773CE60D3 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:48:36 LOG7[8]: Initializing application specific data for session authenticated 2020.12.21 14:48:36 LOG7[8]: New session callback 2020.12.21 14:48:36 LOG7[8]: Deallocating application specific data for session connect address 2020.12.21 14:48:36 LOG6[8]: Session id: AF8ED185555C6734403C71B514A3F6B75F8484A5AC4EAE6058CFF4D35D929B36 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSLv3/TLS read server session ticket 30 sec delay 2020.12.21 14:49:06 LOG6[8]: Read socket closed (readsocket) 2020.12.21 14:49:06 LOG7[8]: Sending close_notify alert 2020.12.21 14:49:06 LOG7[8]: TLS alert (write): warning: close notify 2020.12.21 14:49:06 LOG6[8]: SSL_shutdown successfully sent close_notify alert 2020.12.21 14:49:06 LOG3[8]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing 2020.12.21 14:49:06 LOG7[8]: FD=4540 ifds=--x ofds=--- 2020.12.21 14:49:06 LOG7[8]: FD=4792 ifds=r-x ofds=--- 2020.12.21 14:49:06 LOG5[8]: Connection closed: 64 byte(s) sent to TLS, 0 byte(s) sent to socket 2020.12.21 14:49:06 LOG7[8]: Remote descriptor (FD=4792) closed 2020.12.21 14:49:06 LOG7[8]: Local descriptor (FD=4540) closed 2020.12.21 14:49:06 LOG7[8]: Service [SLNP pem file] finished (0 left) log example when stunnel doesn't get stuck: 2020.12.21 14:49:06 LOG6[9]: TLS connected: previous session reused 2020.12.21 14:49:06 LOG6[9]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2020.12.21 14:49:06 LOG6[9]: Peer temporary key: X25519, 253 bits 2020.12.21 14:49:06 LOG7[9]: Compression: null, expansion: null 2020.12.21 14:49:06 LOG6[9]: Session id: AF8ED185555C6734403C71B514A3F6B75F8484A5AC4EAE6058CFF4D35D929B36 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:49:06 LOG7[9]: Initializing application specific data for session authenticated 2020.12.21 14:49:06 LOG7[9]: New session callback 2020.12.21 14:49:06 LOG7[9]: Deallocating application specific data for session connect address 2020.12.21 14:49:06 LOG6[9]: Session id: 44E9010787EFDBC0FCA92724415AD30EF9EDB626D734D894061606C79CD26402 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSLv3/TLS read server session ticket 2020.12.21 14:49:06 LOG6[9]: Read socket closed (readsocket) 2020.12.21 14:49:06 LOG7[9]: Sending close_notify alert 2020.12.21 14:49:06 LOG7[9]: TLS alert (write): warning: close notify 2020.12.21 14:49:06 LOG6[9]: SSL_shutdown successfully sent close_notify alert 2020.12.21 14:49:06 LOG3[9]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing 2020.12.21 14:49:06 LOG7[9]: FD=2464 ifds=r-x ofds=--- 2020.12.21 14:49:06 LOG7[9]: FD=2788 ifds=--x ofds=--- 2020.12.21 14:49:06 LOG5[9]: Connection closed: 64 byte(s) sent to TLS, 108 byte(s) sent to socket 2020.12.21 14:49:06 LOG7[9]: Remote descriptor (FD=2464) closed 2020.12.21 14:49:06 LOG7[9]: Local descriptor (FD=2788) closed 2020.12.21 14:49:06 LOG7[9]: Service [SLNP pem file] finished (0 left) My stunnel conf: debug = 7 output = stunnel.log fips = no options = NO_SSLv2 [SLNP pem file] key = SLNP_urmsand01_new.pem cert = SLNP_urmsand01_new.pem client = yes accept = 8003 connect = host:6443 TIMEOUTbusy = 30 TIMEOUTclose = 0 TIMEOUTconnect = 60 TIMEOUTidle = 86400 With the old stunnel(5.14) it doesn’t happen. Thanks, Ditty.

3 3

stunnel is stuck for 30 seconds
by Brent Kimberley 23 Dec '20

23 Dec '20

Chris/Ditty. Have you tried optimizing your config - on both sides? For example, please search for TIMEOUTbusy in https://github.com/mtrojnar/stunnel/tree/stunnel-5.58 &/| https://github.com/mtrojnar/stunnel/tree/stunnel-5.57 On 12/21/20 13:09, dittyadler(a)gmail.com wrote: > Hi, > > I'm running stunnel version 5.58 on Windows, > everything works perfectly besides that sometimes stunnel gets stuck for 30 seconds - > Nothing special in stunnel log, except for the 30 seconds delay: >

1 0

stunnel is stuck for 30 seconds
by dittyadler＠gmail.com 21 Dec '20

21 Dec '20

Hi, I'm running stunnel version 5.58 on Windows, everything works perfectly besides that sometimes stunnel gets stuck for 30 seconds - Nothing special in stunnel log, except for the 30 seconds delay: 2020.12.21 14:48:36 LOG6[8]: TLS connected: previous session reused 2020.12.21 14:48:36 LOG6[8]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2020.12.21 14:48:36 LOG6[8]: Peer temporary key: X25519, 253 bits 2020.12.21 14:48:36 LOG7[8]: Compression: null, expansion: null 2020.12.21 14:48:36 LOG6[8]: Session id: 8E62D0D8EB6359FEA7370E64AA7CC58EF9DB68059A5E01417E7038B773CE60D3 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:48:36 LOG7[8]: Initializing application specific data for session authenticated 2020.12.21 14:48:36 LOG7[8]: New session callback 2020.12.21 14:48:36 LOG7[8]: Deallocating application specific data for session connect address 2020.12.21 14:48:36 LOG6[8]: Session id: AF8ED185555C6734403C71B514A3F6B75F8484A5AC4EAE6058CFF4D35D929B36 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSLv3/TLS read server session ticket 30 sec delay 2020.12.21 14:49:06 LOG6[8]: Read socket closed (readsocket) 2020.12.21 14:49:06 LOG7[8]: Sending close_notify alert 2020.12.21 14:49:06 LOG7[8]: TLS alert (write): warning: close notify 2020.12.21 14:49:06 LOG6[8]: SSL_shutdown successfully sent close_notify alert 2020.12.21 14:49:06 LOG3[8]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing 2020.12.21 14:49:06 LOG7[8]: FD=4540 ifds=--x ofds=--- 2020.12.21 14:49:06 LOG7[8]: FD=4792 ifds=r-x ofds=--- 2020.12.21 14:49:06 LOG5[8]: Connection closed: 64 byte(s) sent to TLS, 0 byte(s) sent to socket 2020.12.21 14:49:06 LOG7[8]: Remote descriptor (FD=4792) closed 2020.12.21 14:49:06 LOG7[8]: Local descriptor (FD=4540) closed 2020.12.21 14:49:06 LOG7[8]: Service [SLNP pem file] finished (0 left) log example when stunnel doesn't get stuck: 2020.12.21 14:49:06 LOG6[9]: TLS connected: previous session reused 2020.12.21 14:49:06 LOG6[9]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2020.12.21 14:49:06 LOG6[9]: Peer temporary key: X25519, 253 bits 2020.12.21 14:49:06 LOG7[9]: Compression: null, expansion: null 2020.12.21 14:49:06 LOG6[9]: Session id: AF8ED185555C6734403C71B514A3F6B75F8484A5AC4EAE6058CFF4D35D929B36 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:49:06 LOG7[9]: Initializing application specific data for session authenticated 2020.12.21 14:49:06 LOG7[9]: New session callback 2020.12.21 14:49:06 LOG7[9]: Deallocating application specific data for session connect address 2020.12.21 14:49:06 LOG6[9]: Session id: 44E9010787EFDBC0FCA92724415AD30EF9EDB626D734D894061606C79CD26402 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSLv3/TLS read server session ticket 2020.12.21 14:49:06 LOG6[9]: Read socket closed (readsocket) 2020.12.21 14:49:06 LOG7[9]: Sending close_notify alert 2020.12.21 14:49:06 LOG7[9]: TLS alert (write): warning: close notify 2020.12.21 14:49:06 LOG6[9]: SSL_shutdown successfully sent close_notify alert 2020.12.21 14:49:06 LOG3[9]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing 2020.12.21 14:49:06 LOG7[9]: FD=2464 ifds=r-x ofds=--- 2020.12.21 14:49:06 LOG7[9]: FD=2788 ifds=--x ofds=--- 2020.12.21 14:49:06 LOG5[9]: Connection closed: 64 byte(s) sent to TLS, 108 byte(s) sent to socket 2020.12.21 14:49:06 LOG7[9]: Remote descriptor (FD=2464) closed 2020.12.21 14:49:06 LOG7[9]: Local descriptor (FD=2788) closed 2020.12.21 14:49:06 LOG7[9]: Service [SLNP pem file] finished (0 left) My stunnel conf: debug = 7 output = stunnel.log fips = no options = NO_SSLv2 [SLNP pem file] key = SLNP_urmsand01_new.pem cert = SLNP_urmsand01_new.pem client = yes accept = 8003 connect = host:6443 TIMEOUTbusy = 30 TIMEOUTclose = 0 TIMEOUTconnect = 60 TIMEOUTidle = 86400 With the old stunnel(5.14) it doesn’t happen. Thanks, Ditty.

1 0

stunnel is stuck for 30 seconds
by DITTY ADLER 21 Dec '20

21 Dec '20

Hi, I'm running stunnel version 5.58 on Windows, everything works perfectly besides that sometimes stunnel gets stuck for 30 seconds - Nothing special in stunnel log, except for the 30 seconds delay: 2020.12.21 14:48:36 LOG6[8]: TLS connected: previous session reused 2020.12.21 14:48:36 LOG6[8]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2020.12.21 14:48:36 LOG6[8]: Peer temporary key: X25519, 253 bits 2020.12.21 14:48:36 LOG7[8]: Compression: null, expansion: null 2020.12.21 14:48:36 LOG6[8]: Session id: 8E62D0D8EB6359FEA7370E64AA7CC58EF9DB68059A5E01417E7038B773CE60D3 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:48:36 LOG7[8]: Initializing application specific data for session authenticated 2020.12.21 14:48:36 LOG7[8]: New session callback 2020.12.21 14:48:36 LOG7[8]: Deallocating application specific data for session connect address 2020.12.21 14:48:36 LOG6[8]: Session id: AF8ED185555C6734403C71B514A3F6B75F8484A5AC4EAE6058CFF4D35D929B36 2020.12.21 14:48:36 LOG7[8]: TLS state (connect): SSLv3/TLS read server session ticket 30 sec delay 2020.12.21 14:49:06 LOG6[8]: Read socket closed (readsocket) 2020.12.21 14:49:06 LOG7[8]: Sending close_notify alert 2020.12.21 14:49:06 LOG7[8]: TLS alert (write): warning: close notify 2020.12.21 14:49:06 LOG6[8]: SSL_shutdown successfully sent close_notify alert 2020.12.21 14:49:06 LOG3[8]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing 2020.12.21 14:49:06 LOG7[8]: FD=4540 ifds=--x ofds=--- 2020.12.21 14:49:06 LOG7[8]: FD=4792 ifds=r-x ofds=--- 2020.12.21 14:49:06 LOG5[8]: Connection closed: 64 byte(s) sent to TLS, 0 byte(s) sent to socket 2020.12.21 14:49:06 LOG7[8]: Remote descriptor (FD=4792) closed 2020.12.21 14:49:06 LOG7[8]: Local descriptor (FD=4540) closed 2020.12.21 14:49:06 LOG7[8]: Service [SLNP pem file] finished (0 left) log example when stunnel doesn't get stuck: 2020.12.21 14:49:06 LOG6[9]: TLS connected: previous session reused 2020.12.21 14:49:06 LOG6[9]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2020.12.21 14:49:06 LOG6[9]: Peer temporary key: X25519, 253 bits 2020.12.21 14:49:06 LOG7[9]: Compression: null, expansion: null 2020.12.21 14:49:06 LOG6[9]: Session id: AF8ED185555C6734403C71B514A3F6B75F8484A5AC4EAE6058CFF4D35D929B36 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSL negotiation finished successfully 2020.12.21 14:49:06 LOG7[9]: Initializing application specific data for session authenticated 2020.12.21 14:49:06 LOG7[9]: New session callback 2020.12.21 14:49:06 LOG7[9]: Deallocating application specific data for session connect address 2020.12.21 14:49:06 LOG6[9]: Session id: 44E9010787EFDBC0FCA92724415AD30EF9EDB626D734D894061606C79CD26402 2020.12.21 14:49:06 LOG7[9]: TLS state (connect): SSLv3/TLS read server session ticket 2020.12.21 14:49:06 LOG6[9]: Read socket closed (readsocket) 2020.12.21 14:49:06 LOG7[9]: Sending close_notify alert 2020.12.21 14:49:06 LOG7[9]: TLS alert (write): warning: close notify 2020.12.21 14:49:06 LOG6[9]: SSL_shutdown successfully sent close_notify alert 2020.12.21 14:49:06 LOG3[9]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing 2020.12.21 14:49:06 LOG7[9]: FD=2464 ifds=r-x ofds=--- 2020.12.21 14:49:06 LOG7[9]: FD=2788 ifds=--x ofds=--- 2020.12.21 14:49:06 LOG5[9]: Connection closed: 64 byte(s) sent to TLS, 108 byte(s) sent to socket 2020.12.21 14:49:06 LOG7[9]: Remote descriptor (FD=2464) closed 2020.12.21 14:49:06 LOG7[9]: Local descriptor (FD=2788) closed 2020.12.21 14:49:06 LOG7[9]: Service [SLNP pem file] finished (0 left) My stunnel conf: debug = 7 output = stunnel.log fips = no options = NO_SSLv2 [SLNP pem file] key = SLNP_urmsand01_new.pem cert = SLNP_urmsand01_new.pem client = yes accept = 8003 connect = host:6443 TIMEOUTbusy = 30 TIMEOUTclose = 0 TIMEOUTconnect = 60 TIMEOUTidle = 86400 With the old stunnel(5.14) it doesn’t happen. Thanks, Ditty.

1 0

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

EHLO localhost causing problem in smtp-relay.gmail.com
by sreyas-n＠hcl.com 11 Dec '20

11 Dec '20

We note that always EHLO command sent by sTunnel to SMTP server always been populated as "localhost". Note some well know SMTP server (or) SMTP relay servers such as smtp-relay.gmail.com, etc reject further communication with SMTP clients (as here sTunnel), if they receive initial handshake EHLO request itself as LOCALHOST. Please refer this link on why SMTP servers/ relay servers reject EHLO command with LOCALHOST - https://support.google.com/a/answer/2956491. Note because of this reason, we could use sTunnel as our encryption channel to communicate with SMTP server/relay server. Is there any specific reason behind in hardcoding the EHLO command with LOCALHOST always even in latest version of sTunnel - 5.57 version..? Always what would be in sTunnel functionality, if we change the EHLO command to populate as hostname (or) FQDN instead.

1 0

EHLO localhost
by sreyas-n＠hcl.com 11 Dec '20

11 Dec '20

We note that always EHLO command sent by sTunnel to SMTP server always been populated as "localhost". Note some well know SMTP server (or) SMTP relay servers such as smtp-relay.gmail.com, etc reject further communication with SMTP clients (as here sTunnel), if they receive initial handshake EHLO request itself as LOCALHOST. Please refer this link on why SMTP servers/ relay servers reject EHLO command with LOCALHOST - https://support.google.com/a/answer/2956491. Note because of this reason, we could use sTunnel as our encryption channel to communicate with SMTP server/relay server. Is there any specific reason behind in hardcoding the EHLO command with LOCALHOST always even in latest version of sTunnel - 5.57 version..? Always what would be in sTunnel functionality, if we change the EHLO command to populate as hostname (or) FQDN instead.

1 0

Segmentation fault on the stunnel 5.57 running on RHEL7
by paulrbk＠gmail.com 11 Dec '20

11 Dec '20

Hi All we have a segmentation fault on the stunnel 5.57 running on RHEL7 Dec 10 16:54:32 prod001 kernel: stunnel[1572]: segfault at 278 ip 00007f3fdca229c2 sp 00007f3fd9011a28 error 6 in libssl.so.1.0.2k[7f3fdc9da000+67000] $ uname -a Linux prod001 3.10.0-1160.2.1.el7.x86_64 #1 SMP Mon Sep 21 21:00:09 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa|grep openssl openssl-devel-1.0.2k-19.el7.x86_64 xmlsec1-openssl-1.2.20-7.el7_4.x86_64 openssl-1.0.2k-19.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 below is the configuration =================================== pid = /home/admin/run/stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 #debug = 2 debug = 7 output = /home/admin/log/stunnel.log ######################################################## ### ### INSTANCE 1: program1 ### ### Tunnel for remote connection (Server_aaS) ### [program1-remote-to-local] cert = /home/admin/config/certs/prod001.crt key = /home/admin/config/certs/prod001.key accept = 192.168.1.33:7011 connect = 192.168.1.33:7001 ### Tunnel for local connection ### [program1-local-to-local] client = yes CAfile = /home/admin/config/certs/prod001.crt accept = 127.0.0.1:7011 connect = 192.168.1.33:7011 ### Tunnel to connect remote Tunnel ### SERVER-02 192.168.1.34:7021 ### [program1-01-to-02] client = yes CAfile = /home/admin/config/certs/prod002.crt accept = 192.168.1.33:7021 connect = 192.168.1.34:7021 ========================================== $ ./stunnel -help Initializing inetd mode configuration stunnel 5.57 on x86_64-pc-linux-gnu platform Compiled/running with OpenSSL 1.0.2k-fips 26 Jan 2017 Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI Global options: chroot = directory to chroot stunnel process compression = compression type EGD = path to Entropy Gathering Daemon socket engine = auto|engine_id engineCtrl = cmd[:arg] engineDefault = TASK_LIST fips = yes|no FIPS 140-2 mode foreground = yes|quiet|no foreground mode (don't fork, log to stderr) log = append|overwrite log file output = file to append log messages pid = pid file RNDbytes = bytes to read from random seed files RNDfile = path to file with random seed data RNDoverwrite = yes|no overwrite seed datafiles with new random data syslog = yes|no send logging messages to syslog Service-level options: accept = [host:]port accept connections on specified host:port CApath = CA certificate directory for 'verify' option CAfile = CA certificate file for 'verify' option cert = certificate chain checkEmail = peer certificate email address checkHost = peer certificate host name pattern checkIP = peer certificate IP address ciphers = permitted ciphers for TLS 1.2 or older client = yes|no client mode (remote service uses TLS) config = command[:parameter] to execute connect = [host:]port to connect CRLpath = CRL directory CRLfile = CRL file curves = ECDH curve names debug = [facility].level (e.g. daemon.info) delay = yes|no delay DNS lookup for 'connect' option engineId = ID of engine to read the key from engineNum = number of engine to read the key from exec = file execute local inetd-type program execArgs = arguments for 'exec' (including $0) failover = rr|prio failover strategy ident = username for IDENT (RFC 1413) checking include = directory with configuration file snippets key = certificate private key local = IP address to be used as source for remote connections logId = connection identifier type OCSP = OCSP responder URL OCSPaia = yes|no check the AIA responders from certificates OCSPflag = OCSP responder flags OCSPnonce = yes|no send and verify the OCSP nonce extension options = TLS option to set/reset protocol = protocol to negotiate before TLS initialization currently supported: cifs, connect, imap, nntp, pgsql, pop3, proxy, smtp, socks protocolAuthentication = authentication type for protocol negotiations protocolDomain = domain for protocol negotiations protocolHost = host:port for protocol negotiations protocolPassword = password for protocol negotiations protocolUsername = username for protocol negotiations PSKidentity = identity for PSK authentication PSKsecrets = secrets for PSK authentication pty = yes|no allocate pseudo terminal for 'exec' option redirect = [host:]port to redirect on authentication failures renegotiation = yes|no support renegotiation requireCert = yes|no require client certificate reset = yes|no send TCP RST on error retry = yes|no retry connect+exec section service = service name setgid = groupname for setgid() setuid = username for setuid() sessionCacheSize = session cache size sessionCacheTimeout = session cache timeout (in seconds) sessiond = [host:]port use sessiond at host:port sni = master_service:host_name for an SNI virtual service socket = a|l|r:option=value[:value] set an option on accept/local/remote socket sslVersion = all|SSLv2|SSLv3|TLSv1|TLSv1.1|TLSv1.2 TLS method stack = thread stack size (in bytes) ticketKeySecret = secret key for encryption/decryption TLSv1.3 tickets ticketMacSecret = key for HMAC operations on TLSv1.3 tickets TIMEOUTbusy = seconds to wait for expected data TIMEOUTclose = seconds to wait for close_notify TIMEOUTconnect = seconds to connect remote host TIMEOUTidle = seconds to keep an idle connection transparent = none|source|destination|both transparent proxy mode verify = level of peer certificate verification verifyChain = yes|no verify certificate chain verifyPeer = yes|no verify peer certificate

1 0

Stunnel and CAPI engine: Issues after OpenSSL upgrade on server side
by Brent Kimberley 10 Dec '20

10 Dec '20

It looks like IBM might have been able to get MS CAPI to work with TLS1.2. That said, I think it would make more sense to switch to CNG API.

2 2