stunnel-users

stunnel-users@stunnel.org

6 participants
3294 discussions

stunnel become non-non responsive and very sluggish
by Joe Phillips 18 Mar '19

18 Mar '19

I have 5.30 running on Ubuntu workstation. It has become sluggish and almost non responsive at times. I captured this in the log the other day...no source, no destination address. Maybe got stuck in a loop? Have to restart Ubuntu to clear it up. stunnel2@stunnel2:~$ /etc/init.d/stunnel4 restart [....] Restarting stunnel4 (via systemctl): stunnel4.serviceFailed to restart stunnel4.service: Access denied See system logs and 'systemctl status stunnel4.service' for details. failed! stunnel2@stunnel2:~$ sudo tail -f -n 100 /var/log/stunnel.log sudo: unable to resolve host stunnel2: Connection timed out [sudo] password for stunnel2: 2019.03.13 04:06:14 LOG5[1149140]: Connection reset: 34440 byte(s) sent to SSL, 4886 byte(s) sent to socket 2019.03.13 04:38:56 LOG5[1142702]: Connection reset: 2362 byte(s) sent to SSL, 1225 byte(s) sent to socket 2019.03.13 05:09:32 LOG5[1137283]: Connection reset: 23006 byte(s) sent to SSL, 3977 byte(s) sent to socket 2019.03.13 05:51:57 LOG5[1109534]: Connection reset: 33953 byte(s) sent to SSL, 16755 byte(s) sent to socket 2019.03.13 05:58:36 LOG5[1139715]: Connection reset: 25039 byte(s) sent to SSL, 3944 byte(s) sent to socket 2019.03.13 06:25:12 LOG5[1137757]: Connection reset: 2863 byte(s) sent to SSL, 1329 byte(s) sent to socket 2019.03.13 06:49:19 LOG5[1137393]: Connection reset: 26536 byte(s) sent to SSL, 14839 byte(s) sent to socket 2019.03.13 06:51:35 LOG5[1137344]: Connection reset: 28968 byte(s) sent to SSL, 12986 byte(s) sent to socket 2019.03.13 07:10:28 LOG5[1137343]: Connection reset: 28655 byte(s) sent to SSL, 7632 byte(s) sent to socket 2019.03.13 07:30:52 LOG5[1136403]: Connection reset: 25466 byte(s) sent to SSL, 6767 byte(s) sent to socket 2019.03.13 07:35:33 LOG5[1141675]: Connection reset: 28637 byte(s) sent to SSL, 15044 byte(s) sent to socket 2019.03.13 07:39:21 LOG5[1121823]: Connection reset: 47442 byte(s) sent to SSL, 67336 byte(s) sent to socket 2019.03.13 07:39:58 LOG5[1148822]: Connection reset: 25003 byte(s) sent to SSL, 9295 byte(s) sent to socket 2019.03.13 07:40:29 LOG5[1127468]: Connection reset: 57030 byte(s) sent to SSL, 73806 byte(s) sent to socket 2019.03.13 07:46:08 LOG5[1107655]: Connection reset: 84608 byte(s) sent to SSL, 125726 byte(s) sent to socket 2019.03.13 07:49:49 LOG5[1140561]: Connection reset: 27344 byte(s) sent to SSL, 11112 byte(s) sent to socket 2019.03.13 07:59:23 LOG5[1106646]: Connection reset: 9970 byte(s) sent to SSL, 5355 byte(s) sent to socket 2019.03.13 08:01:27 LOG5[1143613]: Connection reset: 26733 byte(s) sent to SSL, 8993 byte(s) sent to socket 2019.03.13 08:02:28 LOG5[1141251]: Connection reset: 49897 byte(s) sent to SSL, 62187 byte(s) sent to socket 2019.03.13 08:03:11 LOG5[1139045]: Connection reset: 24669 byte(s) sent to SSL, 4580 byte(s) sent to socket 2019.03.13 08:05:13 LOG5[1137322]: Connection reset: 39408 byte(s) sent to SSL, 33428 byte(s) sent to socket 2019.03.13 08:07:56 LOG5[1151696]: Connection reset: 23577 byte(s) sent to SSL, 5415 byte(s) sent to socket 2019.03.13 08:11:12 LOG5[1136170]: Connection reset: 64684 byte(s) sent to SSL, 36839 byte(s) sent to socket 2019.03.13 08:11:55 LOG5[1141693]: Connection reset: 22826 byte(s) sent to SSL, 5186 byte(s) sent to socket 2019.03.13 08:15:30 LOG5[1140377]: Connection reset: 42452 byte(s) sent to SSL, 39471 byte(s) sent to socket 2019.03.13 08:18:29 LOG5[1154893]: Connection reset: 21190 byte(s) sent to SSL, 3096 byte(s) sent to socket 2019.03.13 08:22:14 LOG5[1153488]: Connection reset: 23506 byte(s) sent to SSL, 5081 byte(s) sent to socket 2019.03.13 08:24:34 LOG5[1153167]: Connection reset: 46285 byte(s) sent to SSL, 8378 byte(s) sent to socket 2019.03.13 08:26:25 LOG5[1145557]: Connection reset: 26015 byte(s) sent to SSL, 6055 byte(s) sent to socket 2019.03.13 08:29:34 LOG5[1030096]: Connection reset: 89657 byte(s) sent to SSL, 120807 byte(s) sent to socket 2019.03.13 08:30:36 LOG5[1081623]: Connection reset: 51409 byte(s) sent to SSL, 50378 byte(s) sent to socket 2019.03.13 08:32:23 LOG5[1149449]: Connection reset: 28329 byte(s) sent to SSL, 12655 byte(s) sent to socket 2019.03.13 08:32:33 LOG5[1106312]: Connection reset: 52138 byte(s) sent to SSL, 58239 byte(s) sent to socket 2019.03.13 08:33:46 LOG5[1137325]: Connection reset: 36900 byte(s) sent to SSL, 29750 byte(s) sent to socket 2019.03.13 08:36:35 LOG5[1145147]: Connection reset: 31740 byte(s) sent to SSL, 21114 byte(s) sent to socket 2019.03.13 08:38:59 LOG5[1133239]: Connection reset: 44816 byte(s) sent to SSL, 18743 byte(s) sent to socket 2019.03.13 08:41:04 LOG5[1148129]: Connection reset: 32191 byte(s) sent to SSL, 20525 byte(s) sent to socket 2019.03.13 08:43:55 LOG5[1150567]: Connection reset: 27989 byte(s) sent to SSL, 12627 byte(s) sent to socket 2019.03.13 08:47:21 LOG5[1146666]: Connection reset: 29242 byte(s) sent to SSL, 13836 byte(s) sent to socket 2019.03.13 08:49:26 LOG5[main]: Terminated 2019.03.13 08:58:32 LOG5[ui]: stunnel 5.30 on x86_64-pc-linux-gnu platform 2019.03.13 08:58:32 LOG5[ui]: Compiled/running with OpenSSL 1.0.2g 1 Mar 2016 2019.03.13 08:58:32 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP 2019.03.13 08:58:32 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2019.03.13 08:58:32 LOG5[ui]: UTF-8 byte order mark detected 2019.03.13 08:58:32 LOG5[ui]: FIPS mode disabled 2019.03.13 08:58:36 LOG5[ui]: Configuration successful [UMC Color Logo - small]<http://www.universalmoney.com/> Joe Phillips SVP-IT 15301 W. 87th Street Parkway, Suite 215 Lenexa, KS 66219 Corp Office 913.831.2055 Direct via Cell 913.927.5691 www.universalmoney.com

2 1

(no subject)
by Vijay Raghavan P 05 Mar '19

05 Mar '19

Hi, I have to create tunnel between server and client. Client have proxy configured in between. So i use below in /etc/stunnel/stunnel.config pid = /var/run/stunnel.pid cert = /home/client.crt key = /home/client.key options = NO_SSLv2 debug = 7 output = /var/log/stunnel4/stunnel.log client = yes CAfile=/home/**chain.pem verify=2 [test] protocol = connect accept = 127.0.0.1:10000 protocolHost = server.xxxx.com:443 connect = <PROXYIP>:<PROXY port> protocolUsername = user1 protocolPassword = password protocolAuthentication = Basic then i bring up the service. With above configuration connection works file. Now i don't want proxy password to be clear text in this case. Any pointers plz Thanks, Vj

2 3

Re: [stunnel-users] stunnel-users Digest, Vol 176, Issue 3
by Andrew Smalley 04 Mar '19

04 Mar '19

FIPS in stunnel and OpenSSL The actual cause of the problem is OpenSSL v1.1.x does not support FIPS engine and as such, you can only use a FIPS Compliant cipher until FIPS is recertified as I understand it Andruw Smalley Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 asmalley(a)loadbalancer.org Leave a Review | Deployment Guides | Blog Andruw Smalley Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 asmalley(a)loadbalancer.org Leave a Review | Deployment Guides | Blog On Mon, 4 Mar 2019 at 16:20, <stunnel-users-request(a)stunnel.org> wrote: > > Send stunnel-users mailing list submissions to > stunnel-users(a)stunnel.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users > or, via email, send a message with subject or body 'help' to > stunnel-users-request(a)stunnel.org > > You can reach the person managing the list at > stunnel-users-owner(a)stunnel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of stunnel-users digest..." > > > Today's Topics: > > 1. FIPS mode not supported (Yan Renelt) > 2. Re: FIPS mode not supported (mlrx) > 3. Re: FIPS mode not supported (Flo Rance) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Mar 2019 16:14:47 +0100 > From: Yan Renelt <reneltyan(a)gmail.com> > To: stunnel-users(a)stunnel.org > Subject: [stunnel-users] FIPS mode not supported > Message-ID: <3F804E14-5218-42A5-9850-7AEBC0EF8F96(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > my config is > cert = stunnel.pem > socket = l:TCP_NODELAY=1 > socket = r:TCP_NODELAY=1 > debug = 7 > > fips = yes > > [Demo-Trading] > client = yes > accept = 127.0.0.1:40001 > connect = fix-order.london-demo.lmax.com:443 > sslVersion = TLSv1 > options = NO_SSLv2 > options = NO_SSLv3 > > [Demo ñ Market Data] > client = yes > accept = 127.0.0.1:40003 > connect = fix-marketdata.london-demo.lmax.com:443 > sslVersion = TLSv1 > options = NO_SSLv2 > options = NO_SSLv3 > > > and I still receiving this error. > > FIPS_mode_set: F06D065: error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported > > Any suggestions? Fips = no is not an option for me. > > > Thanks > > Yan >

1 0

FIPS mode not supported
by Yan Renelt 04 Mar '19

04 Mar '19

Hi, my config is cert = stunnel.pem socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 fips = yes [Demo-Trading] client = yes accept = 127.0.0.1:40001 connect = fix-order.london-demo.lmax.com:443 sslVersion = TLSv1 options = NO_SSLv2 options = NO_SSLv3 [Demo ñ Market Data] client = yes accept = 127.0.0.1:40003 connect = fix-marketdata.london-demo.lmax.com:443 sslVersion = TLSv1 options = NO_SSLv2 options = NO_SSLv3 and I still receiving this error. FIPS_mode_set: F06D065: error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported Any suggestions? Fips = no is not an option for me. Thanks Yan

3 2

dhparam and others
by mlrx 02 Mar '19

02 Mar '19

Hello, This is my first run with stunnel. I have unbound and stunnel on openBSD to do DNS-over-TLS and it works (fine). I want now to enforce TLS security so I added the following options: sslVersion = TLSv1.2 options = CIPHER_SERVER_PREFERENCE ciphers = [list] curve = [name] When it will be ready to production, I will add: verify = 3 CA* OCSP* For now, I don't find any information about using dhparam file. Something like SSLOpenSSLConfCmd DHParameters "/path/to/file.pem" in Apache. How can I do it possible? Could you point me some informations or the path to do it please? Could you confirm that I can't use TLS1.3 for now in stunnel? May be you could have some security advices ? Best regards, -- mlrx

1 0

Issue with NTLM authorisation
by Vijay Raghavan P 01 Mar '19

01 Mar '19

Hi, I have to create tunnel between server and client. Client have proxy configured in between. So i use below in /etc/stunnel/stunnel.config. User name and password is correct pid = /var/run/stunnel.pid cert = /home/client.crt key = /home/client.key options = NO_SSLv2 debug = 7 output = /var/log/stunnel4/stunnel.log client = yes CAfile=/home/**chain.pem verify=2 [test] protocol = connect accept = 127.0.0.1:10000 protocolHost = host.vmj.com:443 connect = <PROXYIP>:<PROXY port> protocolUsername = vmj.com\user1 protocolPassword = VMJTEST!123 protocolAuthentication = NTLM In stunnel.log, i can see below error 2019.02.28 18:36:50 LOG6[2103:140737354032896]: Client-mode connect protocol negotiations started 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> CONNECT host.vmj.com:443 HTTP/1.1 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> Host: host.vmj.com:443 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> Proxy-Connection: keep-alive 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> Proxy-Authorization: NTLM TlRMTVNTUAABAAAAAgIAAA== 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- HTTP/1.1 407 Proxy Authentication Required 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Server: squid/3.3.8 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Mime-Version: 1.0 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Date: Thu, 28 Feb 2019 18:36:33 GMT 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Content-Type: text/html 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Content-Length: 3285 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Vary: Accept-Language 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Content-Language: en 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAADgAAAACAgACueAMGSlaSZ0AAAAAAAAAAAAAAAA4AAAABgEAAAAAAA8= 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- X-Cache: MISS from squidproxy.vmj.com 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- X-Cache-Lookup: NONE from squidproxy.vmj.com:3128 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Via: 1.1 squidproxy.vmj.com (squid/3.3.8) 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Connection: keep-alive 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> CONNECT host.vmj.com:443 HTTP/1.1 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> Host: host.vmj.com:443 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> Proxy-Authorization: NTLM TlRMTVNTUAADAAAAAAAAAGcAAAAYABgAQAAAAAAAAABnAAAADwAPAFgAAAAAAAAAZwAAAAAAAABnAAAAAgIAAAGbqH5v5ML8msrfm3R1yDBsS+ai3ldihnZybmkuY29tXGJoYXJ0aQ== 2019.02.28 18:36:50 LOG7[2103:140737354032896]: -> 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- HTTP/1.1 407 Proxy Authentication Required 2019.02.28 18:36:50 LOG3[2103:140737354032896]: CONNECT request rejected 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Server: squid/3.3.8 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Mime-Version: 1.0 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Date: Thu, 28 Feb 2019 18:36:33 GMT 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Content-Type: text/html 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Content-Length: 3363 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Vary: Accept-Language 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Content-Language: en 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Proxy-Authenticate: NTLM 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- X-Cache: MISS from squidproxy.vmj.com 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- X-Cache-Lookup: NONE from squidproxy.vmj.com:3128 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Via: 1.1 squidproxy.vmj.com (squid/3.3.8) 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- Connection: keep-alive 2019.02.28 18:36:50 LOG7[2103:140737354032896]: <- 2019.02.28 18:36:50 LOG5[2103:140737354032896]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket 2019.02.28 18:36:50 LOG7[2103:140737354032896]: Remote socket (FD=14) closed 2019.02.28 18:36:50 LOG7[2103:140737354032896]: Local socket (FD=3) closed 2019.02.28 18:36:50 LOG7[2103:140737354032896]: Service [test] finished (0 left) If i try with basic authentication it works fine. Its urgent , can some one help me out. Thanks, Vj

2 1

Tunnel from win32 to Unix
by Eetu Pikkarainen 26 Feb '19

26 Feb '19

Hi, I am a totally newbie with this. We have intranet system in Windows Server (32bit) which reads a database (Oracle) situated in Unix machine via a tunnel made by Putty.exe. That works well except that the connection gets lost every now and then and it must be manually logged in every time. So I decided to try stunnel which we used earlier to read email from email server. However I cannot set the connection successfully. This is what I have tried now (among many other alternatives): [Kanto2] client = yes accept = 127.0.0.1:1501 connect = kanto2.oulu.fi:22 protocolUsername = <username> protocolPassword = <password> stunnel reads the configuration OK except this notification: [:] Service [Kanto2] needs authentication to prevent MITM attacks but when the database is tried to read happens this: 2019.02.18 13:32:30 LOG5[1]: Service [Kanto2] accepted connection from 127.0.0.1:64699 2019.02.18 13:32:30 LOG5[1]: s_connect: connected 130.231.240.100:22 2019.02.18 13:32:30 LOG5[1]: Service [Kanto2] connected remote server from 130.231.241.250:64700 2019.02.18 13:32:30 LOG3[1]: SSL_connect: 140770FC: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol 2019.02.18 13:32:30 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket I have tried different protocol alternatives with no help. What could be the problem? Is this kind of use even possible? thanks Eetu Pikkarainen PhD (Ed.), (Title of) Adjunct Prof., University Lecturer (in Education) Faculty of Education, University of Oulu, Finland Research Group: https://wiki.oulu.fi/display/theored Latest publications: Semiotic Theory of Learning: New Perspectives in the Philosophy of Education. By Andrew Stables, Winfried Nöth, Alin Olteanu, Sébastien Pesce and Eetu Pikkarainen https://www.taylorfrancis.com/books/e/9781351725170 Schools in Transition: Linking Past, Present, and Future in Educational Practice. Edited by Pauli Siljander, Kimmo Kontio and Eetu Pikkarainen https://www.sensepublishers.com/catalogs/bookseries/other-books/schools-in-…

2 1

Stunnel 3.50 Win - CAPI stopped working
by pepak＠seznam.cz 18 Feb '19

18 Feb '19

Hello, I have encountered a bug in Stunnel version 3.50. I have a setup with two computers (Server and Client) connected using Stunnel. The client is using a hardware token through the CAPI engine to authenticate itself to a server, using a config file: ----- fips = no taskbar = yes options = NO_SSLv2 options = NO_SSLv3 sslVersion = TLSv1.2 engine = capi [my-server] client = yes accept = 22 connect = my.server.com:1234 requireCert = yes verifyChain = yes verifyPeer = yes CAfile = my-cert-chain.pem engineId = capi ----- This setup works perfectly in Stunnel 3.49: When I try to connect to localhost:22, I receive a request to select a certificate and enter its PIN, and if successful, a connection to my server is established. In Stunnel 3.50, the connection fails to complete. The Stunnel log shows: LOG5[0]: Service [my-server] accepted connection from 127.0.0.1:49713 LOG5[0]: s_connect: connected 1.2.3.4:1234 LOG5[0]: Service [my-server] connected remote server from 10.11.12.13:49714 LOG5[0]: Certificate accepted at depth=0: CN=My server LOG3[0]: error queue: 141F0006: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib LOG3[0]: SSL_connect: 8006F074: error:8006F074:lib(128):capi_rsa_priv_enc:function not supported LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket However, if I change the engine to the default one and use a certificate in file, everything works fine. That suggests to me that the problem lies in the Stunnel's CAPI engine library. It is quite possible the problem is caused by the CAPI engine itself. I was experimenting with OpenSSL 1.1.1a some time back, trying to compile my own library files, and I just couldn't to get CAPI to work at all - the libraries themselves compiled OK and worked fine, but the CAPI engine just wouldn't work (while it was OK with OpenSSL 1.0.2q); the only way I could get CAPI to work with OpenSSL 1.1.1a was to use the 1.1.1a libraries and the 1.0.2q capi.dll. However, I am far from an expert on compiling OpenSSL, so I may have gotten it completely wrong. Could someone please verify that their CAPI engine is working with Stunnel? Also, it may be worth trying to compile a 64bit CAPI.dll from version 1.0.2q just to see if it might start working - in that case, a bug report to OpenSSL may be in order. Thanks. pepak

2 1

Timeout's issue / network stunnel on virtual apps
by Marian Andrei Olteanu 17 Feb '19

17 Feb '19

Hi all, I have a client - server application which works as following. The server is hosted in a linux machine and the clients are up in citrix(XEN) virtual machines. I have enable stunnel encry. in between this environments but i keep getting some connection issues from time to time. To be more clear the client application starts a session for you from the virtual machine (xen) so the stunnel.exe running there in the server is meant to encrypt traffic of around 100 users(from win AD who have access to use that resource in the server) , port configured in VM machine 1001 accept - linux.host:1002 connect with linux accept on 1002 - localhost:1000. the channel opened between the VM and Linux is used by many users simultaneous. Could please tell me what is happening here?Is this architecture able to work? thank you in advance. Marian

1 0

stunnel stopped working today, had to reboot server
by Christopher Schultz 14 Feb '19

14 Feb '19

Hello, I'm new to the list so I'm sorry if this isn't the right place to report this. I had a server stop responding to stunnel connections sometime yesterday and the resolution was ultimately to reboot the server and everything was okay. Restarting the stunnel service was not enough to get things working again. I isolated the problem to stunnel by checking that the underlying service (a Java web application) would respond from the localhost machine (it did) but an openssl s_client connection to localhost:stunnel-port would connect but not proceed past the CONNECTED(3) state. Ultimately, it would time-out. stunnel was not logging anything to syslog when these connections came in. Outgoing stunnel connections seemed to be okay. Looking through the log file, I could see that there were some odd messages coming from stunnel in the daemon.log file suggesting that there might be a memory leak. I won't post them here unless requested, as they may represent a potential security issue. My concern is that a service-restart for stunnel was not sufficient. This suggests a problem which goes deeper than the stunnel service. Is it possible for stunnel to break in such a way that it continues to be broken after a restart? I'm sorry, in retrospect, I was not 100% sure that the service did indeed stop and launch a new process when running /etc/init.d/stunnel restart, but there were no errors and the service-runner did report that the service was restarted. My (simplified) configuration and version information is posted below. Please let me know if there is any other information I might be able to provide in order to investigate this. Note that this is a package-managed version of stunnel, provided by the Debian package-maintainers. Thanks, -chris PS Thanks for a wonderful product. I've relied on stunnel for years to proxy these unencrypted AJP connections for me. Cheers for all your great work. Configuration: === CUT === cert = /etc/stunnel/stunnel.crt key = /etc/stunnel/stunnel.pem sslVersion = TLSv1.2 options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 pid = /stunnel4-ajp.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 verify = 4 CAfile = /etc/stunnel/stunnel-ajp-trusted.pem [now, a series of 4 services, all configured similarly] accept=public-port connect=localhost:private-port === CUT === Version: stunnel 5.39 on x86_64-pc-linux-gnu platform Compiled with OpenSSL 1.1.0c 10 Nov 2016 Running with OpenSSL 1.1.0j 20 Nov 2018 Update OpenSSL shared libraries or rebuild stunnel Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP Global options: debug = daemon.notice pid = /var/run/stunnel4.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes Service-level options: ciphers = FIPS (with "fips = yes") ciphers = HIGH:+3DES:+DH:!aNULL:!SSLv2 (with "fips = no") curve = prime256v1 debug = notice logId = sequential options = NO_SSLv2 options = NO_SSLv3 sessionCacheSize = 1000 sessionCacheTimeout = 300 seconds stack = 65536 bytes TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds verify = none Linux kernel version: Linux [hostname] 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux This is running on a bare metal server.

2 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users