stunnel-users

[email protected]

1 participants
3311 discussions

Start a nNew thread

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:[email protected]> > 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:[email protected]> > 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:[email protected]> roam(a)debian.org <mailto:[email protected]> pp(a)storpool.com <mailto:[email protected]> 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:[email protected] > 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:[email protected] 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users