stunnel-users June 2024

stunnel-users@stunnel.org

11 participants
9 discussions

stunnel - client conexion close by TLS alert (write) fatal decode error
by Rodigo Alvarez 07 Mar '25

07 Mar '25

Hi All! I would appreciate any clue to solve the problem we are having with a client mode service that stopped working this week (we verified that the service works directly without stunnel). The error I identify in the trace is the following: "TLS alert (write): fatal: decode error" Stunnel Config (windows version): [afip-prod-fce] client = yes accept = ARSASSRV4DMS06:1031 connect = serviciosjava.afip.gob.ar:443 debug = 7 ws: https://serviciosjava.afip.gob.ar/wsfecred/FECredService Complete trace: 2024.01.24 09:28:46 LOG5[main]: stunnel 5.71 on x64-pc-mingw32-gnu platform 2024.01.24 09:28:46 LOG5[main]: Compiled/running with OpenSSL 3.1.3 19 Sep 2023 2024.01.24 09:28:46 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI 2024.01.24 09:28:46 LOG5[main]: Reading configuration from file C:\Program Files (x86)\stunnel\config\stunnel.conf 2024.01.24 09:28:46 LOG5[main]: UTF-8 byte order mark detected 2024.01.24 09:28:46 LOG5[main]: FIPS mode disabled 2024.01.24 09:28:46 LOG4[main]: Service [afip-prod-fce] needs authentication to prevent MITM attacks 2024.01.24 09:28:46 LOG5[main]: Configuration successful 2024.01.24 09:29:23 LOG7[0]: Service [afip-prod-fce] started 2024.01.24 09:29:23 LOG7[0]: Setting local socket options (FD=892) 2024.01.24 09:29:23 LOG7[0]: Option TCP_NODELAY set on local socket 2024.01.24 09:29:23 LOG5[0]: Service [afip-prod-fce] accepted connection from 10.70.162.24:57723 2024.01.24 09:29:23 LOG6[0]: s_connect: connecting 200.1.116.19:443 2024.01.24 09:29:23 LOG7[0]: s_connect: s_poll_wait 200.1.116.19:443: waiting 10 seconds 2024.01.24 09:29:23 LOG7[0]: FD=896 ifds=rwx ofds=--- 2024.01.24 09:29:24 LOG5[0]: s_connect: connected 200.1.116.19:443 2024.01.24 09:29:24 LOG5[0]: Service [afip-prod-fce] connected remote server from 10.72.0.69:64788 2024.01.24 09:29:24 LOG7[0]: Setting remote socket options (FD=896) 2024.01.24 09:29:24 LOG7[0]: Option TCP_NODELAY set on remote socket 2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) initialized 2024.01.24 09:29:24 LOG6[0]: SNI: sending servername: serviciosjava.afip.gob.ar 2024.01.24 09:29:24 LOG6[0]: Peer certificate not required 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): before SSL initialization 2024.01.24 09:29:24 LOG7[0]: Initializing application specific data for session authenticated 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG6[0]: CERT: Certificate verification disabled 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server key exchange 2024.01.24 09:29:24 LOG7[0]: OCSP stapling: Client callback called 2024.01.24 09:29:24 LOG6[0]: OCSP: Certificate chain verification disabled 2024.01.24 09:29:24 LOG6[0]: Client certificate not requested 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read server done 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write client key exchange 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read change cipher spec 2024.01.24 09:29:24 LOG7[0]: TLS state (connect): SSLv3/TLS read finished 2024.01.24 09:29:24 LOG7[0]: New session callback 2024.01.24 09:29:24 LOG7[0]: Peer certificate was cached (6643 bytes) 2024.01.24 09:29:24 LOG6[0]: Session id: D63C79766AC02C9A3E8494AD528954A183E9F7C250856695BA05C16A2219A4B3 2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) requested 2024.01.24 09:29:24 LOG7[0]: 1 client connect(s) succeeded 2024.01.24 09:29:24 LOG7[0]: 0 client renegotiation(s) requested 2024.01.24 09:29:24 LOG7[0]: 0 session reuse(s) 2024.01.24 09:29:24 LOG6[0]: TLS connected: new session negotiated 2024.01.24 09:29:24 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption) 2024.01.24 09:29:24 LOG6[0]: Peer temporary key: ECDH, P-256, 256 bits 2024.01.24 09:29:24 LOG7[0]: Compression: null, expansion: null 2024.01.24 09:29:24 LOG7[0]: Remove session callback 2024.01.24 09:29:24 LOG7[0]: TLS alert (write): fatal: decode error 2024.01.24 09:29:24 LOG6[0]: TLS socket closed (SSL_read) 2024.01.24 09:29:24 LOG7[0]: Sent socket write shutdown 2024.01.24 09:29:24 LOG5[0]: Connection closed: 1755 byte(s) sent to TLS, 634 byte(s) sent to socket 2024.01.24 09:29:24 LOG7[0]: Remote descriptor (FD=896) closed 2024.01.24 09:29:24 LOG7[0]: Local descriptor (FD=892) closed 2024.01.24 09:29:24 LOG7[0]: Service [afip-prod-fce] finished (0 left) Thank you! Kind regards, Rodrigo.

3 3

Requests to cloud server that requires host header
by Lorne Kates 13 Nov '24

13 Nov '24

(related to Akamai message from before-- but I have better troubleshooting information). I'm tying to route traffic through stunnel to a "cloud" based-endpoint. That endpoint has a static server name-- test.authorize.net. (This is the dev sandbox for auth.net). But if you do an nslookup on test.authorize.net, you'll get back a different servername and IP, because it's so wonderfully "cloud". Stunnel apparently tries to connect to the nslookup value. The server rejects the request because it can't route it back to test.authorize.net. I've tried adding "delay = yes" and "sni = test.authorize.net", but neither work. To see this in action, a simple setup with any accept, then connect to test.authorize.net:443 in client = yes mode. This is what a valid response looks like (13 -- give me the darn merchant ID in a POST): https://test.authorize.net/gateway/transact.dll This is what you'll get if you try to use stunnel (400 invalid url) : https://23.195.204.150/gateway/transact.dll So how can I get stunnel to send the proper Request Header (host: test.authorize.net), make sure it's using http/1.1, etc?

4 3

Re: [stunnel-users] CPU 100%
by Eric Eberhard 06 Nov '24

06 Nov '24

Long ago I had a server with a bad network card. Every once in a while it would spew uncontrollable bytes onto the network. If you open a stunnel connection and it does that this could very well be the problem. If it cheap, try changing the network card. If not, you should be able to look in your firewall/router and it will tell you who is sending what bytes to whomever. See if that machine is indeed streaming the bytes in massive quantities. If not, I would suspect your stunnel is getting stuck in it's own loop. There are a million reasons this can happen (well a few less than a million) - such as maybe a bad library in the FreeBSD or a bad choice in the Makefile - such as doing threads or something in a way your O/S does not like (I use threads=fork or whatever it is, instead of actual threading). You might tinker with some of the options that make the stunnel build and try different ones. Especially if stunnel was compiled on a different version of the O/S - could be differences in bytes in things and who knows what. That is all I can suggest beyond setting the debug level to 7 (I think is highest) and then watching the log file. Eric From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Murrey, Brian J. Sent: Wednesday, October 17, 2018 10:57 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] CPU 100% We are running stunnel 5.49 on FreeBSD 11.2 and we're running into a problem once in a while. CPU pegs at 100% when we get an stunnel connection from one of our external devices. This affects 100% of all cores and we can't even log in to console. To mitigate this temporarily, we have a script running in the background to watch when stunnel begins to spike and restarts the daemon. It doesn't happen 100% of the time, and so far I have been unable to distinguish what makes the connection do this to the CPU. Have any of you run in to this issue? Sincerely, Brian Murrey System Engineer II, IT Infrastructure _____ NOTICE: This message may contain privileged and confidential information and/or protected health information intended solely for the use of the named recipient and may be privileged or otherwise protected by law. If you are not the intended recipient of this message, you should immediately notify the sender and delete this message. Do not disseminate, reproduce, or review this message or attachments if you are not the intended recipient. The sender or others may have legal rights restricting the dissemination of the information contained in this message and, as a result, remedies against you in the event of the improper dissemination of confidential information, trade secrets, personal information or privileged communications. This message is the work of the sender and does not necessarily reflect the position, views, or policies of TriMedx LLC or its affiliates. WARNING: The integrity and security of this message cannot be guaranteed and may contain or transmit a virus or other illicit code. Neither TriMedx LLC or its affiliates accept liability for any damage attributable to viruses or illicit code transmitted through this message or an attachment.

2 1

stunnel for postgres
by Casey & Gina 10 Aug '24

10 Aug '24

Hi! I'm trying to set up stunnel for postgres, and cannot get it working. For the moment, I'm just trying to test locally on a Mac. I have set up postgres SSL correctly and confirmed that direct connections to the db with psql work with SSL. Here's the most promising config I've come up with: foreground = yes client = yes [postgresql] protocol = pgsql accept = 127.0.0.1:5433 connect = 127.0.0.1:5432 verify = 0 cert = /opt/homebrew/var/postgresql(a)16/server.crt key = /opt/homebrew/var/postgresql(a)16/server.key CAfile = /opt/homebrew/var/postgresql(a)16/ca.crt Here's what I'm getting: $ PGSSLMODE=disable psql -h 127.0.0.1 -p 5432 -U casey -d postgres -c 'select 1' -At 1 $ PGSSLMODE=require psql -h 127.0.0.1 -p 5432 -U casey -d postgres -c 'select 1' -At 1 $ PGSSLMODE=disable psql -h 127.0.0.1 -p 5433 -U casey -d postgres -c 'select 1' -At psql: error: connection to server at "127.0.0.1", port 5433 failed: server offered SCRAM-SHA-256-PLUS authentication over a non-SSL connection $ PGSSLMODE=require psql -h 127.0.0.1 -p 5433 -U casey -d postgres -c 'select 1' -At psql: error: connection to server at "127.0.0.1", port 5433 failed: FATAL: unsupported frontend protocol 1234.5679: server supports 3.0 to 3.0 Also, is it possible to connect to stunnel via UNIX socket instead of TCP? Thanks, -- Casey

3 2

How to specify OCSP responder URL in "server" mode?
by sbworkde＠gmail.com 02 Jul '24

02 Jul '24

I want to specify OCSP responder URL while stunnel in "server" mode. I tried to use the option "OCSP" in configuration file, but it only works in "client" mode. The OCSP responder URL is always read form AIA while stunnel is in "server" mode, even when I set "OCSPaia = no". Is there a way to specify OCSP resonder URL for "server" mode?

2 1

Stunnel with tinyproxy seem failed to forward
by jensen＠fixes.hk 29 Jun '24

29 Jun '24

Stunnel config client = no cert = /path/to/fullchain.pem key = /path/to/privkey.pem pid = /var/run/stunnel4/stunnel.pid debug = 7 output = /var/log/stunnel4/stunnel.log [tinyproxy] accept = 0.0.0.0:8443 connect = 127.0.0.1:7777 here's the log 2024.06.28 11:08:26 LOG7[main]: Found 1 ready file descriptor(s) 2024.06.28 11:08:26 LOG7[main]: FD=4 events=0x2001 revents=0x0 2024.06.28 11:08:26 LOG7[main]: FD=9 events=0x2001 revents=0x1 2024.06.28 11:08:26 LOG7[main]: Service [tinyproxy] accepted (FD=3) from X.X.X.X:42086 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] started 2024.06.28 11:08:26 LOG7[3]: Setting local socket options (FD=3) 2024.06.28 11:08:26 LOG7[3]: Option TCP_NODELAY set on local socket 2024.06.28 11:08:26 LOG5[3]: Service [tinyproxy] accepted connection from X.X.X.X:42086 2024.06.28 11:08:26 LOG6[3]: Peer certificate not required 2024.06.28 11:08:26 LOG7[3]: TLS state (accept): before SSL initialization 2024.06.28 11:08:26 LOG3[3]: SSL_accept: ../ssl/record/ssl3_record.c:348: error:0A00009B:SSL routines::https proxy request 2024.06.28 11:08:26 LOG5[3]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2024.06.28 11:08:26 LOG7[3]: local_rfd/local_wfd reset (FD=3) 2024.06.28 11:08:26 LOG7[3]: Local descriptor (FD=3) closed 2024.06.28 11:08:26 LOG7[3]: Service [tinyproxy] finished (0 left) on connect, I'm using server with OS Ubuntu16.04 with OpenSSL 1.1.1n 15 Mar 2022 (Library: OpenSSL 1.1.1 11 Sep 2018). using my other server (OS ubuntu 2X.) and my local (Mac OS), I'm able to connect to stunnel + tinyproxy successfully. it seems the issue within the server with Ubuntu16.04 or did I miss other config ?

3 5

Devo Relay(Stunnel) -> Palo Alto Log Ingestion Configuration
by jeykipamca＠hotmail.com 14 Jun '24

14 Jun '24

Hi!, I am trying to ingest Palo Alto Firewall syslogs from Devo SIEM, to do that, I had to implement Stunnel on my relay server but in the installation part, I got this error message (I couldn't start stunnel service and I set all the configs as mentioned below links); devo-relay-server:/etc/stunnel# systemctl status stunnel4.service × stunnel4.service - LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons) Loaded: loaded (/etc/init.d/stunnel4; generated) Active: failed (Result: exit-code) since Fri 2024-06-14 13:42:04 UTC; 58min ago Docs: man:systemd-sysv-generator(8) CPU: 27ms Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [.] Reading configuration from file /etc/stunnel/stunnel.conf Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [.] UTF-8 byte order mark not detected Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [!] /etc/stunnel/stunnel.conf:6: "setuid = test": Illegal UID Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [!] Configuration failed Jun 14 13:42:04 -devo-relay-server stunnel4[4032]: [ ] Deallocating temporary section defaults Jun 14 13:42:04 -devo-relay-server stunnel4[4018]: failed Jun 14 13:42:04 -devo-relay-server stunnel4[4018]: You should check that you have specified the pid= in you configuration file Jun 14 13:42:04 -devo-relay-server systemd[1]: stunnel4.service: Control process exited, code=exited, status=1/FAILURE Jun 14 13:42:04 -devo-relay-server systemd[1]: stunnel4.service: Failed with result 'exit-code'. Jun 14 13:42:04 -devo-relay-server systemd[1]: Failed to start LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons). root@-devo-relay-server:/etc/stunnel# -------------------------------------------------------------- My conf file; /etc/stunnel/stunnel.conf ; ************************************************************************** ; * Global options * ; ************************************************************************** ; It is recommended to drop root privileges if stunnel is started by root setuid = test setgid = test ; PID file is created inside the chroot jail (if enabled) pid = /var/run/stunnel4/stunnel.pid ; Debugging stuff (may be useful for troubleshooting) ;foreground = yes ;debug = debug output = /var/log/stunnel4/stunnel.log [firewall_tunnel] client = no accept = 6515 connect = 127.0.0.1:13005 cert = /etc/pki/stunnel/cert_SyslogCert-Devo.pem verifyChain = yes verifyPeer = yes CAfile = /etc/pki/stunnel/cert_RootCA-Devo.crt -------------------------------------------------------------- /etc/default/stunnel4 file; # /etc/default/stunnel # Julien LEMOINE <speedblue(a)debian.org> # September 2003 ENABLED=1 FILES="/etc/stunnel/*.conf" OPTIONS="" # Change to one to enable ppp restart scripts PPP_RESTART=0 # Change to enable the setting of limits on the stunnel instances # For example, to set a large limit on file descriptors (to enable # more simultaneous client connections), set RLIMITS="-n 4096" # More than one resource limit may be modified at the same time, # e.g. RLIMITS="-n 4096 -d unlimited" RLIMITS="" -------------------------------------------------------------- Does anyone have knowledge about the issue? The links which I got support. https://docs.devo.com/space/latest/94663679/Sending+Palo+Alto+events+to+Dev… https://docs.devo.com/space/latest/96469881/Sending+SSL%2FTLS+encrypted+eve…

1 0

Can I use stunnel to create a proxy chain?
by Eugene Bos 11 Jun '24

11 Jun '24

Hello. I have a proxy with http/socks5 support but this configuration doesnt work: client = yes [my-proxy] accept = 127.0.0.1:9666 connect = proxy.com:10000 protocol = connect protocolHost = username__cr.ua:password@proxy.com:10000 I wanted to proxy requests sent to 127.0.0.1:9666 to username__cr.ua:p assword@proxy.com:10000

1 0

help required with stunnel cipher set up
by Glick, Daniel 11 Jun '24

11 Jun '24

Classification: Restricted Dear All, Objective : We have been informed by Euroclear that we must use the following ciphers below with our stunnel connection to them TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Server details : [cid:image001.png@01DABB28.6D132C70] The required cipher has been defined as being the first in the list. [cid:image002.png@01DABB28.6D132C70] Information security has confirmed that the cipher has been enabled [cid:image006.png@01DABB29.42BE4530] However after rebooting the server and starting stunnel – the old ciphers are still being used [cid:image003.png@01DABB28.6D132C70] Please can anyone point us in the right direction as to what we are doing wrong. Thank you Daniel Glick Application Specialist, Investment Management & Finance Platform Arbuthnot Latham & Co., Limited ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender and delete it from your system. Internet communications are not secure and therefore Arbuthnot Latham & Co., Limited does not accept legal responsibility for the contents of this message or any damage sustained as a result of this email or its attachments. Any views or opinions presented are solely those of the author and do not necessarily represent those of Arbuthnot Latham & Co., Limited or any of its affiliates. Please take some time to read our Privacy Notice, which provides information on what personal data we collect from you, what we do with it and who it might be shared with. *********************************************************************** Arbuthnot Latham & Co., Limited Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Arbuthnot Latham & Co., Limited, DIFC Branch, is regulated by the Dubai Financial Services Authority ("DFSA"). Registered in England and Wales 819519. Registered office: Arbuthnot House 7 Wilson Street London EC2M 2SN Tel : 020 7012 2500 Fax : 020 7012 2501 ************************************************************************

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users June 2024