- stunnel-users - stunnel.org

Does stunnel support OCSP stapling?
by koalabearguo＠gmail.com 24 Apr '21

24 Apr '21

Will it plan to support in the future? Thanks.

3 2

Re: Fwd: Re: Local socket keeps listening
by Eberhard 16 Apr '21

16 Apr '21

I’ll toss in an unpopular opinion here. I have used stunnel since day one. I had over the years problems with it not answering or the parent process dying altogether and other issues. I finally decided to run it from inetd rather than as a service. It is logical that this is a little slower but with modern machines I don’t notice it. inetd always is running. Always. If it is not you pretty much cannot use the machine. It has been a service program forever and is dead reliable. What you get is total reliability for an unnoticeable loss of speed. I suppose a heavily loaded machine running at capacity might not like this – my answer is throw hardware at it. I need reliable more than anything else. I’d at least try it! E VICS, LLC Eric S Eberhard 2933 W Middle Verde Rd Camp Verde, AZ 86322 928-567-3727 (land line) 928-301-7537 (cell phone) <http://www.vicsmba.com/> http://www.vicsmba.com <https://www.facebook.com/groups/286143052248115> https://www.facebook.com/groups/286143052248115 From: Jorge Redondo Flames <jorge.redondo(a)gmail.com> Sent: Wednesday, April 14, 2021 11:49 AM To: Peter Pentchev <roam(a)ringlet.net> Cc: stunnel-users(a)stunnel.org Subject: [stunnel-users] Re: Fwd: Re: Local socket keeps listening Got it. Thank you very much! On Wed, 14 Apr 2021 at 20:41, Peter Pentchev <roam(a)ringlet.net <mailto:roam@ringlet.net> > wrote: On Wed, Apr 14, 2021 at 08:24:51PM +0200, Jorge Redondo Flames wrote: > On Wed, 14 Apr 2021 at 20:19, Jochen Bern <Jochen.Bern(a)binect.de <mailto:Jochen.Bern@binect.de> > wrote: > > On 14.04.21 19:58, Jorge Redondo Flames wrote: > > > Stunnel could listen on its local port *only* when the peer server is > > > listening on its corresponding server socket. So if there is no serve on > > > the other side, there should not be local listening socket. Does not that > > > make sense? > > > > No. > > > > In the general situation (server *not* being on the same machine as > > stunnel), stunnel CANNOT know whether the server's listening short of > > trying to connect to it - which it will only do on behalf of an incoming > > client request, which would never happen if stunnel weren't listening. > > > > Even if server and stunnel run on the same machine/OS, finding out about > > the server's state would require a bunch of special-purpose code. > > > > Assuming that they *are* on a common Linux (or at least unixoid) system, > > however, it would be rather trivial to write a root cron job that checks > > the output of "ss"/"netstat" for the server's LISTEN and simply > > terminates stunnel if it isn't found. > > > > Or even better, have the server *restarted* automatically whenever it > > croaks ... > > Understood. Although it still seems to me that the code doing more or less > what the cron job would do might worth. So, three points here. 1. There are some services (some servers) that do not react very nicely to somebody connecting to them and disconnecting immediately. Some of them do some work at the moment of the connection (e.g. resolve the client's IP address, check it against firewall rules, or even do some actual, service-specific, work, e.g. allocate buffers, prepare some kind of data...). Some of them are configured in such ways as to avoid portscanners or denial of service attacks or spam or flood or... many other things. In general, unless you *know* that it is safe to connect and immediately disconnect from the remote service, it is very unwise to try to do that. In your particular case, you know that, but in general, it is not a good idea. 2. Even if stunnel would try to connect to the remote service, what happens if the connection fails? OK, you say stunnel should close its local listening socket, but what then - will it never open it again? And if here's the part when you say "it can try to connect to the remote server again and start listening again" - okay, how much time passes between these connection attempts? Even something like a second may be bad if a real client chooses exactly this second to try to connect to stunnel and... stunnel is not listening... even though the remote server has started listening immediately after stunnel's last unsuccessful attempt. So... whatever interval you pick, closing the local listening socket *will* result in real, live clients failing to connect. 3. A more general point: if you really want to check whether a service is operational, only checking whether it will accept a connection is not enough. I've seen *many* failure modes over the years: from an overloaded machine where the OS kernel will accept the connection, but none of the actual server processes will react, through an overloaded service process that accepts the connection but spends too much time processing other requests to pay any attention to it, to a firewall host gone crazy that will pass connection packets, but will then refuse to pass the actual payload (yes, I've seen that happen for at least three different reasons). So an actual service check would be to connect and then send some kind of simple request to the server that you know will not take it too much time and resources to process, but will give you some measure of confidence that the server is actually serving requests and data. But in short, it is impossible for stunnel to know whether a remote server is listening for a connection without trying to connect, it may not be "polite" for it to try to connect too often, and trying to connect not-too-often *will* result in real clients being unable to connect in the intermediate intervals. G'luck, Peter -- Peter Pentchev roam(a)ringlet.net <mailto:roam@ringlet.net> roam(a)debian.org <mailto:roam@debian.org> pp(a)storpool.com <mailto:pp@storpool.com> PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

2 3

Fwd: Re: Local socket keeps listening
by Jorge Redondo Flames 14 Apr '21

14 Apr '21

---------- Forwarded message --------- From: Jorge Redondo Flames <jorge.redondo(a)gmail.com> Date: Wed, 14 Apr 2021 at 19:45 Subject: Re: [stunnel-users] Re: Local socket keeps listening To: Ludolf Holzheid <lholzheid(a)bihl-wiedemann.de> Stunnel could listen on its local port *only* when the peer server is listening on its corresponding server socket. So if there is no serve on the other side, there should not be local listening socket. Does not that make sense? On Wed, 14 Apr 2021 at 19:38, Ludolf Holzheid <lholzheid(a)bihl-wiedemann.de> wrote: > On Wed, 2021-04-14 19:13:03 +0200, Jorge Redondo Flames wrote: > > [..] > > > > Is there a way to configure Stunnel to *close* the local socket (not > > listening anymore) whenever the peer process (i.e. the server) has closed > > its socket? > > Stunnel listens for connection request from the client(s) and connects > to the server on behalf of the client(s). How will a client ever be > able to connect through Stunnel again if Stunnel closes the listening > socket? > > Ludolf > > -- > > Ludolf Holzheid > > Bihl+Wiedemann GmbH > Floßwörthstraße 41 > 68199 Mannheim, Germany > > Tel: +49 621 33996-0 > Fax: +49 621 3392239 > > mailto:lholzheid@bihl-wiedemann.de > https://www.bihl-wiedemann.de > > Sitz der Gesellschaft: Mannheim > Geschäftsführer: Jochen Bihl, Bernhard Wiedemann > Amtsgericht Mannheim, HRB 5796 > > Datenschutzerklärung: https://www.bihl-wiedemann.de/de/meta/datenschutz > _______________________________________________ > stunnel-users mailing list -- stunnel-users(a)stunnel.org > To unsubscribe send an email to stunnel-users-leave(a)stunnel.org >

3 4

Re: Local socket keeps listening
by Ludolf Holzheid 14 Apr '21

14 Apr '21

On Wed, 2021-04-14 19:45:06 +0200, Jorge Redondo Flames wrote: > Stunnel could listen on its local port *only* when the peer server is > listening on its corresponding server socket. So if there is no serve on > the other side, there should not be local listening socket. Does not that > make sense? Stunnel connects to the server only when a client connects to Stunnel. If Stunnel is not listening for clients, it does not try to connect to the server. If it does not try to connect to the server, it does not know if the server is listening. Ludolf > On Wed, 14 Apr 2021 at 19:38, Ludolf Holzheid <lholzheid(a)bihl-wiedemann.de> > wrote: > > > On Wed, 2021-04-14 19:13:03 +0200, Jorge Redondo Flames wrote: > > > [..] > > > > > > Is there a way to configure Stunnel to *close* the local socket (not > > > listening anymore) whenever the peer process (i.e. the server) has closed > > > its socket? > > > > Stunnel listens for connection request from the client(s) and connects > > to the server on behalf of the client(s). How will a client ever be > > able to connect through Stunnel again if Stunnel closes the listening > > socket? > > > > Ludolf -- Ludolf Holzheid Bihl+Wiedemann GmbH Floßwörthstraße 41 68199 Mannheim, Germany Tel: +49 621 33996-0 Fax: +49 621 3392239 mailto:lholzheid@bihl-wiedemann.de https://www.bihl-wiedemann.de Sitz der Gesellschaft: Mannheim Geschäftsführer: Jochen Bihl, Bernhard Wiedemann Amtsgericht Mannheim, HRB 5796 Datenschutzerklärung: https://www.bihl-wiedemann.de/de/meta/datenschutz

2 1

Local socket keeps listening
by Jorge Redondo Flames 14 Apr '21

14 Apr '21

Hey there, thanks for being there. I have a Client/Server services originally communicating over TCP. The client periodically monitors the socket connection by reading from the socket and, in the case the connection has been lost, the client retries the connection a given amount of times, after which it realizes that the server is definitely down. Now I have implemented secure communication using Stunnel and everything works fine except for the fact that, whenever the server process crashes (which is eventually expected), the client is no longer able to successfully monitor the connection as expected since, no matter what happens to the server process, the local Stunnel daemon keeps listening on its local socket. So, when the client retries connection, it successfully connects to the local socket. Although it soon receives connection reset, this successful connection attempt happening even when the server process is actually down completely breaks the client logic. I could change this logic but I really would like to avoid that path. So here is my question: Is there a way to configure Stunnel to *close* the local socket (not listening anymore) whenever the peer process (i.e. the server) has closed its socket? Thank you very much in advance.

2 1

Connection stops after 20 minutes
by erik.delanghe＠outlook.com 07 Apr '21

07 Apr '21

We use Stunnel between a windows server server and a windows client. Everything is working fine exept, after 20 minutes the connection is broken. (Cannot reach the server)

1 1

stunnel 5.59 released
by Michał Trojnara 05 Apr '21

05 Apr '21

Dear Users, I have released version 5.59 of stunnel. ### Version 5.59, 2021.04.05, urgency: HIGH * Security bugfixes - OpenSSL DLLs updated to version 1.1.1k. * New features - Client-side "protocol = ldap" support (thx to Bart Dopheide and Seth Grover). * Bugfixes - The test suite fixed not to require external connectivity. - Fixed paths in generated manuals (thx to Tatsuki Makino). - Fixed configuration reload when compression is used. - Fixed compilation with early releases of OpenSSL 1.1.1. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 137776df6be8f1701f1cd590b7779932e123479fb91e5192171c16798815ce9f stunnel-5.59.tar.gz c45fa3f70ecf0628d1f5985f2c11fedfc989bbc64db857def82ca7ee602fd8e0 stunnel-5.59-win64-installer.exe b56d91493631ff2b18e3e596fbb491892847f5671335c3f5e2307e174742ae44 stunnel-5.59-android.zip Best regards, Mike

1 0

Vulnerabilities cve-2021-3449 and cve-2021-3450
by erik.soudant＠pinkroccade.nl 31 Mar '21

31 Mar '21

Hi, Is there any chance that there will be a new stunnel version (windows) using openssl 1.1.1 k in order to be protected from at least vulnarability cve-2021-3449. And if so when can that be expected? Issue 3450 only concerns1.1.1 H-J so that is not a risk at this moment because the most recent Stunnel version is compiled against 1.1.1c.

2 1

SSL_get_peer_tmp_key fail
by stunnel＠paapnet.nl 28 Mar '21

28 Mar '21

Hai, I just tried compiling stunnel 5.58 but it bails out: CC stunnel-client.o client.c: In function 'print_tmp_key': client.c:670:10: warning: implicit declaration of function 'SSL_get_peer_tmp_key'; did you mean 'SSL_get_server_tmp_key'? [-Wimplicit-function-declaration] if (!SSL_get_peer_tmp_key(s, &key)) { ^~~~~~~~~~~~~~~~~~~~ SSL_get_server_tmp_key CCLD stunnel stunnel-client.o: In function `print_tmp_key': /try/stunnel-5.58/src/client.c:670: undefined reference to `SSL_get_peer_tmp_key' Running Ubuntu Ubuntu 18.04.5 LTS gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) OpenSSL 1.1.1 11 Sep 2018 Version 5.49 compiles ok no issues there Am I missing something here ? Changing it into 'SSL_get_server_tmp_key works' or remming it out probably causes issues... bt it compiles well. Would be great if someone can point me in the right direction. Cheers...

1 0

cross compile for armv7 error, show cannot find ssp_nonshared and ssp
by 583301743＠qq.com 27 Mar '21

27 Mar '21

stunnel.c:306:14: warning: unused variable ‘status’ [-Wunused-variable] 306 | int pid, status; | ^~~~~~ stunnel.c:306:9: warning: unused variable ‘pid’ [-Wunused-variable] 306 | int pid, status; | ^~~ CC stunnel-pty.o CC stunnel-libwrap.o CC stunnel-ui_unix.o CCLD stunnel /mnt/armv5-eabi--uclibc--bleeding-edge-2020.08-1/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.2.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -lssp_nonshared /mnt/armv5-eabi--uclibc--bleeding-edge-2020.08-1/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.2.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: cannot find -lssp when I comment -fstack-protector running error EchoLife_WAP ~ # stunnel -help /mnt/jffs2/app/bin/stunnel: symbol '__ctype_b_loc': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_key_create': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_attr_setstacksize': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_sigmask': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_getspecific': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_create': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'openpty': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_detach': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_setspecific': can't resolve symbol /mnt/jffs2/app/bin/stunnel: symbol 'pthread_join': can't resolve symbol

2 4

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

24 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 hope this can be fixed,thanks.

1 0

Windows Mobile Compiling
by ssj92＠att.net 23 Mar '21

23 Mar '21

Hello, I've been trying to compile latest version of stunnel for wce (WM6) and just cannot get it to work. I have 0 programming experience and have been trying to follow old guides. I was hoping if someone can compile or already has compiled a newer stunnel version for WCE (WM6) other than 5.02. Thanks

1 0

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 21 Mar '21

21 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 17 Mar '21

17 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

New User
by David Rose (dsr) 24 Feb '21

24 Feb '21

Hi I have a Windows app that sends email via SMTP without any authentication (port can be set). I want to use it with Office365 SMTP service which requires TLS. Will stunnel allow me to do this without affecting any other application sending email ? If it does, what terms should I be looking for in the help info ? Many thanks Regards David --

1 0

Windows Server 2012 R2 - localhost:25 stops listening
by Frank Warnke 23 Feb '21

23 Feb '21

Hi, I have noticed that when I install stunnel (stunnel-5.57-win64-installer.exe or today stunnel-5.58-win64-installer.exe) that running "netstat -ano" comes back with; TCP 127.0.0.1:25 0.0.0.0:0 LISTENING 2700 and the application we are using can send email via Gmail SMTP using the default stunnel.config. When I log out the user and go back in, the application can no longer send email via Gmail SMTP and "netstat -ano" no longer sees anything listening on port 25. I have verified that the stunnel service is running and have even stopped and started the stunnel service, but I am not able to get port 25 to be listened to unless I uninstall and install stunnel over again. It seems like something is setup or started during the stunnel install process that stops or gets killed after a user log outs. Any suggestions would be appreciated. Thanks, Frank

2 2

Unable to connect to server using Stunnel with TLS1.2
by jing_pan＠kindermorgan.com 02 Feb '21

02 Feb '21

We failed to using stunnel to connect to remote server which only accept TLS1.2. So we configured the stunnel on our side with below stunnel.conf. We have another program listening to localhost:3500 and process the response from server. I would appreciate any suggestion. 1. Stunnel version: 2021.02.02 10:35:27 LOG5[main]: stunnel 5.58 on x64-pc-mingw32-gnu platform 2021.02.02 10:35:27 LOG5[main]: Compiled/running with OpenSSL 1.1.1h 22 Sep 2020 2021.02.02 10:35:27 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI 2021.02.02 10:35:27 LOG5[main]: Reading configuration from file stunnel.conf 2021.02.02 10:35:27 LOG5[main]: UTF-8 byte order mark not detected 2021.02.02 10:35:27 LOG4[main]: Service [FIXSERVER] needs authentication to prevent MITM attacks 2021.02.02 10:35:27 LOG5[main]: Configuration successful 2. stunnel.conf [FIXSERVER] cert = stunnel.pem client = yes fips = no accept = 127.0.0.1:3000 connect = 63.247.***.***:443 sslVersion = TLSv1.2 3. error returned: An existing connection was forcibly closed by the remote host 4. openssl s_client -connect 63.247.***.***:443 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 2814 bytes and written 419 bytes Verification error: self signed certificate in certificate chain --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE

1 0

Seeing Message in Plain Text in Wireshark
by David Brower 28 Jan '21

28 Jan '21

First time user of Stunnel and I just wanted to check what I'm doing wrong. I have two processes running: a TCP Listener that listens on port 13000 and a TCP client that sends it a message. I'm running Stunnel on Windows 10 with the following config: [myapp] client = yes accept = 13001 connect = 13000 cert = stunnel.pem TIMEOUTclose=0 I updated the TCP client to send the message to port 13001 but when I check Wireshark I can still see the contents of the message in plaintext. Shouldn't I no longer be able to see the unencrypted contents of this message? Here are the relevant logs: 2021.01.27 20:57:26 LOG7[main]: Found 1 ready file descriptor(s) 2021.01.27 20:57:26 LOG7[main]: FD=588 ifds=r-x ofds=r-- 2021.01.27 20:57:26 LOG7[main]: FD=596 ifds=r-x ofds=--- 2021.01.27 20:57:26 LOG7[main]: Service [myapp] accepted (FD=924) from 127.0.0.1:9322 2021.01.27 20:57:26 LOG7[main]: Creating a new thread 2021.01.27 20:57:26 LOG7[main]: New thread created 2021.01.27 20:57:26 LOG7[2]: Service [myapp] started 2021.01.27 20:57:26 LOG7[2]: Setting local socket options (FD=924) 2021.01.27 20:57:26 LOG7[2]: Option TCP_NODELAY set on local socket 2021.01.27 20:57:26 LOG5[2]: Service [myapp] accepted connection from 127.0.0.1:9322 2021.01.27 20:57:26 LOG6[2]: s_connect: connecting 127.0.0.1:13000 2021.01.27 20:57:26 LOG7[2]: s_connect: s_poll_wait 127.0.0.1:13000: waiting 10 seconds 2021.01.27 20:57:26 LOG7[2]: FD=940 ifds=rwx ofds=--- 2021.01.27 20:57:26 LOG5[2]: s_connect: connected 127.0.0.1:13000 2021.01.27 20:57:26 LOG5[2]: Service [myapp] connected remote server from 127.0.0.1:9323 2021.01.27 20:57:26 LOG7[2]: Setting remote socket options (FD=940) 2021.01.27 20:57:26 LOG7[2]: Option TCP_NODELAY set on remote socket 2021.01.27 20:57:26 LOG7[2]: Remote descriptor (FD=940) initialized 2021.01.27 20:57:26 LOG6[2]: SNI: sending servername: localhost 2021.01.27 20:57:26 LOG6[2]: Peer certificate not required 2021.01.27 20:57:26 LOG7[2]: TLS state (connect): before SSL initialization 2021.01.27 20:57:26 LOG7[2]: Initializing application specific data for session authenticated 2021.01.27 20:57:26 LOG7[2]: TLS state (connect): SSLv3/TLS write client hello

3 2

Stunnel intercept and modify payload
by Sealside - 26 Jan '21

26 Jan '21

Hi! I'm wondering if it is possible to modify payload before it is encrypted? I have a stunnel config which intercepts TLS. I have the following config: [server] client = no cert= /etc/stunnel/stunnel.pem accept = 127.0.0.1:11010 connect = 127.0.0.1:12220 [client] client = yes accept = 127.0.0.1:12220 connect = remoteserver_ip:12222 So when posting TLS messages on port 11010 from my TLS-client on the same server, I can connect to port 12220 using tcp-dump and read the payload unencrypted. Is it possible to alter the payload before it is sent? In that case any pointers would be appreciated , I have tried searching but it does not seem to be a common use case. Would be great if I could tunnel it somewhere else and back (external python program). Thanks in advance, S

1 0