- stunnel-users - stunnel.org

report
by Danny Clowes 03 Jan '21

03 Jan '21

sudo find / -name openssl ive checked some locations but im very lost since learning ssl and stunnel i would be happy if you could forward me to the right location & i'll send information back.. Thank you ------------------- /etc/apparmor.d/abstractions/openssl /usr/include/x86_64-linux-gnu/openssl /usr/include/openssl /usr/bin/openssl /usr/share/lintian/overrides/openssl /usr/share/doc/openssl /usr/share/bash-completion/completions/openssl /root/openssl-master/test/ossl_shim/include/openssl /root/openssl-master/include/openssl /snap/core/10577/etc/apparmor.d/abstractions/openssl /snap/core/10577/usr/bin/openssl /snap/core/10577/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl /snap/core/10577/usr/lib/python3/dist-packages/cryptography/hazmat/bindings/openssl /snap/core/10577/usr/share/bash-completion/completions/openssl /snap/core/10577/usr/share/doc/openssl root@debian:/usr/local/include#

1 0

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

Cannot connect using PKI
by Greg Sanders 09 Dec '20

09 Dec '20

Hello, we have been connecting to a test API site where we specified a PEM cert saved locally, and succeeded. I believe this is the 'certificate pinning' approach. Now we are transitioning to the production API, where the tech documentation says there is no certificate needed, "the certificate is sent during the handshake". So a PKI client connection, I guess. But we can't connect. Any suggestions would be appreciated. Our stunnel config is below. Thanks. STUNNEL CONFIG FILE: debug = 7 output = stunnel.log sslVersion = all options = NO_SSLv2 ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM [ice_client] client = yes accept = 127.0.0.1:8080 connect = 63.nnn.nnn.207:443 checkHost = *.xxxxx.com CAfile = ca-certs.pem ; CAPath = certs verifyChain = yes -- Greg Sanders Database Architect Yes Energy

1 0

Stunnel and CAPI engine: Issues after OpenSSL upgrade on server side
by Christian Keck 07 Dec '20

07 Dec '20

Hi there, we just upgraded a system that is used as a TLS-proxy for incoming connections using client-ssl-handshake from an old CentOS 6 to a recent Ubuntu LTS. By doing so, the OpenSSL was updated from 1.0.1e to 1.1.1f. Right after installation, the new OpenSSL complained about "too weak ca cypher", so I had to add a line "CipherString = DEFAULT:@SECLEVEL=1" to the openssl.conf to make things work again. After applying the changes, connections via browsers do work again using TLS 1.3. (We will generate a new host-CA some day, but for now we need a running system) Before the upgrade, Stunnel in CAPI-mode worked wih TLS 1.2 encryption. Now after updating the server, it refused to connect at all. Using version 5.56 of Stunnel, I see the following lines in the log: error queue: ssl/statem/statem_lib.c:298: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib SSL_connect: engines/e_capi.c:814: error:8006F074:lib(128):capi_rsa_priv_enc:function not supported If I nail the protocol setting to TLS1.1 in the apache2-config, the connection is possible again with version 5.56. Any later versions of Stunnel completely refuse to work, I always get lines like: SSL_read: ssl/ssl_rsa.c:36: error:140C618E:SSL routines:SSL_use_certificate:ca md too weak I tried several things I found in the net regarding tweaking openssl.conf and/or stunnel.conf, but I can't get it running with version 5.57 or later. So my questions is: What can I do to get Stunnel working again with at least TLS1.2 (or even better TLS1.3 like I get in most browsers)? Re-generating the host-CA (and thus needing to re-create all client certs) is unfortunately no option for the moment. Many thanks in advance! Cheers, Christian Keck

3 4

Failed to initialize TLS
by Campbell, David 20 Nov '20

20 Nov '20

TLS is not initializing. This is the output. Is there something that I should be including in my conf that would produce this? Or is it just a generic error? [ ] Initializing inetd mode configuration [ ] Running on Windows 6.2 [ ] No limit detected for the number of clients [ ] stunnel 5.57 on x64-pc-mingw32-gnu platform [ ] Compiled/running with OpenSSL 1.1.1h 22 Sep 2020 [ ] Threading WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI [ ] errno: (*_errno()) [ ] GUI message loop initialized [ ] Initializing inetd mode configuration [ ] Running on Windows 6.2 [ . ] Reading configuration from file stunnel.conf [ . ] UTF-8 byte order mark not detected [ ! ] No compression method is available [ ! ] Global options: Failed to initialize TLS [ ! ] Configuration failed [ ] Deallocating temporary section defaults [ ! ] Server is down ________________________________ CONFIDENTIALITY NOTICE: This email constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named recipient(s) intended by the sender of this message. This email, and any attachments, may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, any copying, using, disclosing or distributing to others the information in this email and attachments is STRICTLY PROHIBITED. If you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts or hard copies of the email and attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

1 0

PSK Configuration
by Giulio Regazzo 16 Nov '20

16 Nov '20

Hi, I'm new to stunnel. And I'm trying to configure a server that accepts TCP sockets connections only from clients that have a pre-shared certificate. Looking at the online documentation I found the verifyPeer option, but it is described to be used on client side. Trying to use it on server side I achieved my goal but only if the client has the whole certificate (private + public). My question is: Can I obtain in some way the same result sharing only the public part of the certificate? Currently I'm using a configuration like this one (skipping the accept and connect options): [Server] cert=wholeCert.pem verifyPeer=yes [Client] cert=wholeCert.pem verifyPeer=yes CAFile=wholeCert.pem and I'm looking for something like: [Server] cert=wholeCert.pem verifyPeer=yes [Client] verifyPeer=yes CAFile=publicCert.pem If I try this second option the server refuses the connection in handshake phase saying that the client didn't provide any certificate. Is there a way to achieve this? Thank you.

2 3

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

Stunnel failover
by Ray 02 Nov '20

02 Nov '20

Has anyone tested this scenario with a number of stunnel clients and servers chained in a row with failover capability. The problem is that Stunnel in server mode accepts a connection and performs the SSL handshake before it checks if the connect endpoint is reachable. This causes the downlink client peer wrongly assumes that the link is up and therefore would not try the alternative failover endpoint. You will only observe this problem if you cascade several nodes in a row Ex: Dummy TCP Client <-> Stunnel1 (client) <-> Stunnel2 (server) <-> Stunnel3 (client) <-> Dummy SSL Server In this scenario, dummy client connects to S1, S1 connects to S2 (SSL), S2 tries to connect to S3 but since Dummy SSL server is down, S3 rejects but this rejection is not bouncing back to Dummy Client because S2 has down the downlink handshake and therefore S1 assumes everything is OK. So, the ultimate question is how can we tell Stunnel to first try to connect to endpoints and then send a SYN-ACK back to downlink TCP connection request. This way, a client sends a SYN to Stunnel, Stunnel holds on 3-way handshake, tries to connect to the uplink and completes the downlink handshake only if the uplink connection is OK.

1 0

Stunnel - SSL socket error Connection timed out
by sravan kumar 22 Oct '20

22 Oct '20

Hi Team, Need help on one issue. We recently configured stunnel on our servers for securely establishing DB connections[certs exchanged on stunnel client and server]. Stunnel installed on client machine. Stunnel installed on server machine. Configurations are completed and publishing working for sometime like 1 hr. After that the stunnel on the destination server did not respond and we noticed "SSL socket error: Connection timed out (110)". We made updates to the stunnel.conf with below entries but they are not updating. TIMEOUTclose = 0 TIMEOUTconnect = 200 TIMEOUTidle = 86400 Any help would be greatly appreciated. Regards, Sravan

1 0

5.57 cb_new_auth
by duncan.morris＠cdl.co.uk 20 Oct '20

20 Oct '20

When compiling 5.57 against OpenSSL 1.0.2 I am getting compiler warnings for the cb_new_auth definition. ENGD20 is running V8.4 [840] on ALPHA Building with OpenSSL 1.0.2 Image : STUNNEL.HPE_ALPHA_EXE "session authenticated", cb_new_auth, NULL, NULL); .................................^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "cb_new_auth" is "function (pointer to void, pointer to void, pointer to struct crypto_ex_data_st, int, long, pointer to void) returning void", which is not compatible with "function (pointer to void, pointer to void, pointer to struct crypto_ex_data_st, int, long, pointer to void) returning int" . at line number 80 in file DISK$ORACLE:[STUNNEL_BUILDS.stunnel-557.src]ssl.c;1 This appears to be the result of OpenSSL 1.0.2 defining this as an integer function, whilst 1.1.1 defines it as a void function. Duncan

1 0

Changelog policy / watch out for 5.57 if you have 1024-bit keys in use
by ian.bamforth＠tracsis.com 20 Oct '20

20 Oct '20

Morning, [ ] Loading certificate from file: /opt/clients/certificate_2020-04-23.pem [!] SSL_CTX_use_certificate_chain_file: ssl/ssl_rsa.c:301: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small [!] Service [RailCompanion]: Failed to initialize TLS context [!] Configuration failed We encountered a production outage yesterday when upgrading to 5.57, as it seems that a new securityLevel config has been added, a side-effect of which looks to have been the rejection of certificates of less than 2048 bits by default. We still had a 1024 bit cert in use. Obviously we should've had monitoring to check that stunnel was actually running (we will next time!) but it seems to me like this is a change that deserved more attention in the log, which only identifies it as a new feature, with no mention of breaking changes. Anyway, our problem is now solved, but if you encounter stunnel failing to start when you next upgrade then this might be a candidate to look at. Ian

1 0

Can't Connect To Gmail
by lrogersjunk＠gmail.com 17 Oct '20

17 Oct '20

Hello all - I have tried to set up stunnel to send emails through gmail from a legacy device that can only send to port 25. But I'm having no success. My config file seems correct, as it matches config files posted by others who appear able to send through gmail. This is what it looks like: output = stunnel-log.txt debug = 7 Taskbar = yes [gmail-imap] client = yes accept = 143 connect = imap.gmail.com:993 verifyChain = yes CAfile = ca-certs.pem checkHost = imap.gmail.com OCSPaia = yes [gmail-smtp] client = yes accept = 25 connect = smtp.gmail.com:465 verifyChain = yes CAfile = ca-certs.pem checkHost = smtp.gmail.com OCSPaia = yes I originally thought the problem was gmail's recent new security features, requiring app-passwords for apps that do not support gmail's latest security features. So I set up an app-password for use by stunnel but that didn't work, either. So I then turned on "allow less secure apps" in gmail and used the account's original password (not the app-password). But even that doesn't work. So I'm at a total loss and can't think of anything else to do. Can anyone assist? Many thanks.

4 3

Stunnel & Gmail security
by BOXI31 TEST 16 Oct '20

16 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users