March 2021 - stunnel-users

FIXED cross-compile stunnel lastest version with tls 1.3 suppport base on uclibc
by 583301743＠qq.com 22 Mar '21

22 Mar '21

Thank you for repy I have fix it using --with-threads=fork like CC=arm-linux-gcc CFLAGS="-fno-stack-protector" ./configure --prefix=/mnt/dists/stunnel --with-ssl=/mnt/dists/openssl-v1.1.1j --host=arm-linux --disable-fips --with-random=/dev/urandom --with-threads=fork --disable-libwrap --disable-systemd --disable-ipv6 (you maybe delete stack-protector in configure for cannot find libssp error) and commit #include <ctype.h> in common.c for fix __ctype_b_loc can't resolve symbol and delete all realize code int pty_allocate(int *ptyfd, int *ttyfd, char *namebuf) in pty.c for fix symbol 'openpty': can't resolve symbol like this int pty_allocate(int *ptyfd, int *ttyfd, char *namebuf) { return -1; } and compile openssl with no-threads options CC=arm-linux-gcc ./Configure --prefix=/mnt/dists/openssl-v1.1.1j linux-armv4 no-threads enable-tls1_3 no-asm no-async now running successfully EchoLife_WAP /tmp # ./stunnel -help Initializing inetd mode configuration stunnel 5.58 on arm-unknown-linux-gnu platform Compiled/running with OpenSSL 1.1.1j 16 Feb 2021 Threading:FORK Sockets:POLL,IPv4 TLS:ENGINE,OCSP,PSK,SNI cross-compile stunnel latest version with tls1.3 support is so diffcult. It spend my 2 days to fix problem. I do not why no any guide for cross compile for armv7 not andriod I use cross compile tools-chain is here https://toolchains.bootlin.com/downloads/releases/toolchains/armv5-eabi/tar…

1 1

Possible memory leak in stunnel4 3:5.44-1ubuntu3?
by hkdb 20 Mar '21

20 Mar '21

Hi all, I am currently implementing stunnels on an Ubuntu 18.04 container running Magento 2 connecting to AWS Elasiticache (Redis) with the following configuration: Master: fips = no setuid = nobody setgid = nogroup pid = /home/agent/pids/redis-master.pid debug = 1 delay = yes [redis-cli] client = yes accept = 127.0.0.1:8000 connect = master.awsurl:6379 and the exact same config for the read replica with different "connect" and "accept" values of course. Everything works great except that the container host becomes unresponsive after a few days. Doing a screenshot of the console shows that the host is out of memory and mentions stunnel4 in the same error message. Upon further digging, I found that running the tunnels progressively eats away at RAM over time. Look at the logs when setting debug to 7 shows the following suspect error message: Possible memory leak at ../crypto/asn1/asn1_lib.c:295: 28363 allocations Does anyone have any thoughts on this? Is it a usage/configurations issue or did I discover a memory leak here? If it is in fact a memory leak, does running a later version fix this? Is there a recommended version that I should try to run that's known to work well with Ubuntu 18.04? Thanks a lot in advance for any help on this issue! Regards, Jeremy 3DF Open Source Initiative *Mail: *hkdb(a)3df.io *Web: *https://osi.3df.io

1 0

when reload configure，there is a err (win32)
by koalabearguo＠gmail.com 16 Mar '21

16 Mar '21

hi,I am using the latest version(stunnel5.58) on windows10; compiled openssl 1.1.1j with option zlib enabled; the stunnel.conf file: add option "securityLevel = 0" to enable compression add option "compression = zlib" to enable compression when stunnel start,it work well.but when i reload configuration in the menu configuration，it give me this: SSL_COMP_add_compression_method: ssl\ssl_ciph.c:1997: error:140A5135:SSL routines:SSL_COMP_add_compression_method:duplicate compression id Global options: Failed to initialize TLS Then i search the source code,i found when reload config,the SSL_COMP_add_compression_method(0xe0,mesh) function will add compression id again(duplicate) i think this can be fixed,thanks.

1 0

TLS alert (read): warning: close notify
by Daniel Trickett 08 Mar '21

08 Mar '21

Hi folks, Receiving the message "TLS alert (read): warning: close notify" when initiating connection to another site. I checked logs and we do not get this on any other site we use stunnel to connect to. Is this a message an acknowledgement that stunnel received a close notify message from the external site? 2021.02.25 11:11:17 LOG6[106453]: TLS connected: new session negotiated 2021.02.25 11:11:17 LOG7[106453]: Deallocating application specific data for session connect address 2021.02.25 11:11:17 LOG6[106453]: Negotiated TLSv1.2 ciphersuite ECDHE-ECDSA-AES256-GCM-SHA384 (256-bit encryption) 2021.02.25 11:11:17 LOG7[106453]: Compression: null, expansion: null 021.02.25 11:11:17 LOG7[106453]: TLS alert (read): warning: close notify 2021.02.25 11:11:17 LOG6[106453]: TLS closed (SSL_read) 2021.02.25 11:11:17 LOG7[106453]: Sent socket write shutdown 2021.02.25 11:11:17 LOG6[106453]: Read socket closed (readsocket) 2021.02.25 11:11:17 LOG7[106453]: Sending close_notify alert 2021.02.25 11:11:17 LOG7[106453]: TLS alert (write): warning: close notify 2021.02.25 11:11:17 LOG6[106453]: SSL_shutdown successfully sent close_notify alert 2021.02.25 11:11:17 LOG5[106453]: Connection closed: 9951 byte(s) sent to TLS, 419 byte(s) sent to socket 2021.02.25 11:11:17 LOG7[106453]: Remote descriptor (FD=16) closed 2021.02.25 11:11:17 LOG7[106453]: Local descriptor (FD=15) closed 2021.02.25 11:11:17 LOG7[106453]: Service [xxxx-https] finished (0 left) Best regards, Dan This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.

1 0

Win32 client cron_thread in main_cleanup() lock daemon_thread()
by jony202＠gmail.com 07 Mar '21

07 Mar '21

in main_cleanup() this code blocks because cron_thread has no exit #ifdef USE_WIN32 if(WaitForSingleObject(thread_list[i], INFINITE)==WAIT_FAILED) ioerror("WaitForSingleObject"); if(!CloseHandle(thread_list[i])) ioerror("CloseHandle"); #endif

1 0

Error Stunnel TLS alert (write): fatal: bad record mac
by Alexandre Afonso Vaz 02 Mar '21

02 Mar '21

Hello everyone I apologize in advance because my English is not the best I'm experiencing a problem with stunnel: On the server I'm running a current version [.] stunnel 5.56 on x86_64-pc-linux-gnu platform Compiled / running with OpenSSL 1.1.1d 10 Sep 2019 And on the client an old version [.] stunnel 5.39 on x86_64-pc-linux-gnu platform Compiled with OpenSSL 1.1.0c 10 Nov 2016 The case is that I am having an error in the server log as shown below: SSL_accept: ../ssl/record/ssl3_record.c:677: error: 1408F119: SSL routines: ssl3_get_record: decryption failed or bad record mac I did the test by updating the client to the same version and everything works, the question I have is whether there is really an incompatibility between the versions (be it the stunnel or the openssl). Does anyone know how to confirm me if this is real? Thanks Vaz

1 0

How to insert 2 stunnel.service on redhat 7
by simona vittori 02 Mar '21

02 Mar '21

Hello, I have 2 stunnel instance on a server and I have to insert all 2 in systemd. How to do that? Is it possible to create 2 stunnel.service naming different, for example stunnel.service and stunnel1.service where insert the script to start at boot of the machine? Thanks a lot for you help, Bye Simona

2 2

TLS alert (read): warning: close notify
by Daniel Trickett 01 Mar '21

01 Mar '21

Hi folks, Receiving the message "TLS alert (read): warning: close notify" when initiating connection to another site. I checked logs and we do not get this on any other site we use stunnel to connect to. Is this a message an acknowledgement that stunnel received a close notify message from the external site? 2021.02.25 11:11:17 LOG6[106453]: TLS connected: new session negotiated 2021.02.25 11:11:17 LOG7[106453]: Deallocating application specific data for session connect address 2021.02.25 11:11:17 LOG6[106453]: Negotiated TLSv1.2 ciphersuite ECDHE-ECDSA-AES256-GCM-SHA384 (256-bit encryption) 2021.02.25 11:11:17 LOG7[106453]: Compression: null, expansion: null 021.02.25 11:11:17 LOG7[106453]: TLS alert (read): warning: close notify 2021.02.25 11:11:17 LOG6[106453]: TLS closed (SSL_read) 2021.02.25 11:11:17 LOG7[106453]: Sent socket write shutdown 2021.02.25 11:11:17 LOG6[106453]: Read socket closed (readsocket) 2021.02.25 11:11:17 LOG7[106453]: Sending close_notify alert 2021.02.25 11:11:17 LOG7[106453]: TLS alert (write): warning: close notify 2021.02.25 11:11:17 LOG6[106453]: SSL_shutdown successfully sent close_notify alert 2021.02.25 11:11:17 LOG5[106453]: Connection closed: 9951 byte(s) sent to TLS, 419 byte(s) sent to socket 2021.02.25 11:11:17 LOG7[106453]: Remote descriptor (FD=16) closed 2021.02.25 11:11:17 LOG7[106453]: Local descriptor (FD=15) closed 2021.02.25 11:11:17 LOG7[106453]: Service [xxxx-https] finished (0 left) This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.

1 0