stunnel-users

3306 discussions

Stunnel static compile error while running Make command
by snainwar＠rediffmail.com 28 Apr '21

28 Apr '21

We are trying to static compile stunnel 5.59 with open ssl 1.1.1 on RHEl 6 and RHEL7 we are getting below error running command Make on the server /stunnel-5.59/src/cron.c:239: undefined reference to `BN_GENCB_new' /stunnel-5.59/src/cron.c:244: undefined reference to `BN_GENCB_set' stunnel-cron.o: In function `cron_dh_param': /stunnel-5.59/src/cron.c:219: undefined reference to `CRYPTO_THREAD_write_lock' /stunnel-5.59/src/cron.c:222: undefined reference to `CRYPTO_THREAD_unlock' /stunnel-5.59/src/cron.c:225: undefined reference to `CRYPTO_THREAD_read_lock' /stunnel-5.59/src/cron.c:229: undefined reference to `CRYPTO_THREAD_unlock' stunnel-cron.o: In function `cron_init': /stunnel-5.59/src/cron.c:78: undefined reference to `CRYPTO_THREAD_write_lock' /stunnel-5.59/src/cron.c:81: undefined reference to `CRYPTO_THREAD_unlock' stunnel-stunnel.o: In function `main_cleanup': /stunnel-5.59/src/stunnel.c:249: undefined reference to `CRYPTO_THREAD_write_lock' /stunnel-5.59/src/stunnel.c:263: undefined reference to `CRYPTO_THREAD_unlock' stunnel-stunnel.o: In function `process_connections': /stunnel-5.59/src/stunnel.c:889: undefined reference to `CRYPTO_THREAD_write_lock' /stunnel-5.59/src/stunnel.c:898: undefined reference to `CRYPTO_THREAD_unlock' stunnel-stunnel.o: In function `stunnel_info': /stunnel-5.59/src/stunnel.c:1034: undefined reference to `OpenSSL_version' /stunnel-5.59/src/stunnel.c:1036: undefined reference to `OpenSSL_version' /stunnel-5.59/src/stunnel.c:1041: undefined reference to `OpenSSL_version_num' collect2: error: ld returned 1 exit status make[2]: *** [stunnel] Error 1 make[2]: Leaving directory `/stunnel-5.59/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/stunnel-5.59/src' make: *** [all-recursive] Error 1 [root@tvdcltmp001 stunnel-5.59]#

1 0

Stunnel static compile error while running Make command
by snainwar＠rediffmail.com 28 Apr '21

28 Apr '21

1 0

Unable to reload Stunnel in Linux
by gorf＠hyperfunk.club 27 Apr '21

27 Apr '21

Hi, Normally, I would call "kill -HUP" with Stunnel's process ID to make it reload the configuration in Linux. I was very surprised when I tried that and the process stopped. Why would HUP cause it to exit, rather than reload the config? It doesn't do that on every machine. Thanks.

2 4

Questions about two host connection using stunnel
by yfmao＠seas.upenn.edu 24 Apr '21

24 Apr '21

I am using stunnel4 to build a secure connection between two ubuntu hosts. One of the hosts (sender) will send "hello world" to another host (receiver). When I am using tcpdump in receiver to capture the packets sending from sender, I find out that one of the packets contains "hello world" in plaintext. From my understanding, stunnel will encrypt the content of "hello world" if everything is correct, so I shouldn't be able to see "hello world" in plaintext among any incoming packets. Any ideas about what is going wrong here? Here I will put my stunnel.config for your reference: cert = /home/ubuntu/client_server/stunnel.pem key = /home/ubuntu/client_server/stunnel.key debug = 7 output = /home/ubuntu/client_server/stunnel.log socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 options = ALL [services] accept = 6667 connect = some_ip_address:6666 TIMEOUTclose = 0

4 6

Paid work
by David Rose (dsr) 24 Apr '21

24 Apr '21

I need an Stunnel config that will allow my Windows app that only can send SMTP without any authentication or encryption to be able to send email via Gmail or Office 365. Is this something that someone would be able to write for me and if so, what would you charge ? Thanks David --

3 2

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

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