February 2024 - stunnel-users

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

older browsers, stunnel and privoxy
by kovacs janos 04 Mar '24

04 Mar '24

sorry to bother, im trying to make older browsers be able to display TLS 1.1 and TLS 1.2 sites. i heard stunnel cant be configured to always forward to the current site address dynamically, thats why i would use privoxy. the browser is configured to send to: 127.0.0.1 443 stunnel config has this at the end: [Tunnel_in] client = yes accept = 127.0.0.1:443 connect = 127.0.0.1:8118 verifyChain = yes CAfile = ca-certs.pem checkHost = localhost 127.0.0.1:8118 is the privoxy address. this is what stunnel writes: LOG5[main]: Configuration successful LOG5[0]: Service [Tunnel_in] accepted connection from 127.0.0.1:3261 LOG5[0]: s_connect: connected 127.0.0.1:8118 LOG5[0]: Service [Tunnel_in] connected remote server from 127.0.0.1:3262 and the browser infinitely loads, and never loads anything or leaves the page. if i remove the last 3 lines, its the same just with this line added: LOG4[main]: Service [Tunnel_in] needs authentication to prevent MITM attacks but it doesnt give an error or anything. with a configuration like: [Tunnel_out] client = no accept = 127.0.0.1:443 connect = 127.0.0.1:8118 cert = stunnel.pem this is what it gives: LOG5[3]: Service [Tunnel_out] accepted connection from 127.0.0.1:3294 LOG3[3]: SSL_accept: 1407609B: error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request LOG5[3]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket and browser gives a server not found error immediately. im not even sure if i should use client or server configuration in a case like this, but none of them works anyway. all i would need is for my browser to get the pages decrypted, or at least in less than TLS1.1. like how on newipnow.com i can access sites with any encryption, since they are sent to the browser without encryption. the browser just gives an "unencrypted tunnel" warning, which is how i found stunnel, and which is exactly what i need, just locally.

8 41

How to use best config to secure stunnel?
by sephrrr＠gmail.com 27 Feb '24

27 Feb '24

Irans goverment start to detect stunnel with openvpn tunnel. how to avoid this? is there any updates for stunnel for this problem?

1 0

Windows 2022 tunnel client issues
by Mark Weishaar 23 Feb '24

23 Feb '24

Hello, I’m working on replacing an older Windows server that uses stunnel 5.71 to connect to an Oracle database running on a Linux box. I can communicate just fine with the older Windows machine and another Linux box; however, when I try to connect with the stunnel 5.72 on the Windows 2022 server, I keep running into issues and the connection is forcibly closed. Old Windows server: stunnel 5.71 New Windows 2022 server: stunnel 5.72 (I also tried 5.71 and 5.62 just to rule things out Oracle db server: stunnel 5.72 Other Linux server: stunnel 5.72 My stunnel.conf file is very basic, but this is what is working from my other Windows server (running stunnel 5.71): debug = 7 [oracle15211] client = yes accept = 127.0.0.1:15211 connect = 172.28.125.52:15211 Below is the log with debug level 7… the only issue that I’m seeing is the “transfer() loop executes not transferring any data” message that baffles me but I’m not sure if that’s the cause of my issues or not: 2024.02.23 11:10:21 LOG7[0]: Service [oracle15211] started 2024.02.23 11:10:21 LOG7[0]: Setting local socket options (FD=768) 2024.02.23 11:10:21 LOG7[0]: Option TCP_NODELAY set on local socket 2024.02.23 11:10:21 LOG5[0]: Service [oracle15211] accepted connection from 127.0.0.1:49750 2024.02.23 11:10:21 LOG6[0]: s_connect: connecting 172.28.125.52:15211 2024.02.23 11:10:21 LOG7[0]: s_connect: s_poll_wait 172.28.125.52:15211: waiting 10 seconds 2024.02.23 11:10:21 LOG7[0]: FD=780 ifds=rwx ofds=--- 2024.02.23 11:10:21 LOG5[0]: s_connect: connected 172.28.125.52:15211 2024.02.23 11:10:21 LOG5[0]: Service [oracle15211] connected remote server from 172.28.112.245:49751 2024.02.23 11:10:21 LOG7[0]: Setting remote socket options (FD=780) 2024.02.23 11:10:21 LOG7[0]: Option TCP_NODELAY set on remote socket 2024.02.23 11:10:21 LOG7[0]: Remote descriptor (FD=780) initialized 2024.02.23 11:10:21 LOG6[0]: SNI: sending servername: 172.28.125.52 2024.02.23 11:10:21 LOG6[0]: Peer certificate not required 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): before SSL initialization 2024.02.23 11:10:21 LOG7[0]: Initializing application specific data for session authenticated 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): TLSv1.3 read encrypted extensions 2024.02.23 11:10:21 LOG6[0]: CERT: Certificate verification disabled 2024.02.23 11:10:21 LOG6[0]: CERT: Certificate verification disabled 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): TLSv1.3 read server certificate verify 2024.02.23 11:10:21 LOG7[0]: OCSP stapling: Client callback called 2024.02.23 11:10:21 LOG6[0]: OCSP: Certificate chain verification disabled 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read finished 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2024.02.23 11:10:21 LOG7[0]: 1 client connect(s) requested 2024.02.23 11:10:21 LOG7[0]: 1 client connect(s) succeeded 2024.02.23 11:10:21 LOG7[0]: 0 client renegotiation(s) requested 2024.02.23 11:10:21 LOG7[0]: 0 session reuse(s) 2024.02.23 11:10:21 LOG6[0]: TLS connected: new session negotiated 2024.02.23 11:10:21 LOG6[0]: TLSv1.3 ciphersuite: TLS_AES_256_GCM_SHA384 (256-bit encryption) 2024.02.23 11:10:21 LOG6[0]: Peer temporary key: X25519, 253 bits 2024.02.23 11:10:21 LOG7[0]: Compression: null, expansion: null 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully 2024.02.23 11:10:21 LOG7[0]: Initializing application specific data for session authenticated 2024.02.23 11:10:21 LOG7[0]: Deallocating application specific data for session connect address 2024.02.23 11:10:21 LOG7[0]: New session callback 2024.02.23 11:10:21 LOG7[0]: Peer certificate was cached (1375 bytes) 2024.02.23 11:10:21 LOG6[0]: Session id: B36502A30B16F61EFE3A13B7BAA73BBCD57C2C6DB838FFC7CDFDE9BF7D8607A0 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server session ticket 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSL negotiation finished successfully 2024.02.23 11:10:21 LOG7[0]: Initializing application specific data for session authenticated 2024.02.23 11:10:21 LOG7[0]: New session callback 2024.02.23 11:10:21 LOG7[0]: Deallocating application specific data for session connect address 2024.02.23 11:10:21 LOG6[0]: Session id: 7FC6ABDCD70443FE70736F725F90792FAC2692FD9AD8F54A3F0443C2403C9A0C 2024.02.23 11:10:21 LOG7[0]: TLS state (connect): SSLv3/TLS read server session ticket 2024.02.23 11:10:21 LOG3[0]: transfer() loop executes not transferring any data 2024.02.23 11:10:21 LOG3[0]: please report the problem to Michal.Trojnara(a)stunnel.org<mailto:Michal.Trojnara@stunnel.org> 2024.02.23 11:10:21 LOG3[0]: stunnel 5.72 on x64-pc-mingw32-gnu platform 2024.02.23 11:10:21 LOG3[0]: Compiled/running with OpenSSL 3.2.1 30 Jan 2024 2024.02.23 11:10:21 LOG3[0]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI 2024.02.23 11:10:21 LOG7[0]: errno: (*_errno()) 2024.02.23 11:10:21 LOG3[0]: protocol=TLSv1.3, SSL_pending=0, SSL_has_pending=0 2024.02.23 11:10:21 LOG3[0]: sock_open_rd=Y, sock_open_wr=Y 2024.02.23 11:10:21 LOG3[0]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n 2024.02.23 11:10:21 LOG3[0]: sock_can_rd=n, sock_can_wr=n 2024.02.23 11:10:21 LOG3[0]: ssl_can_rd=n, ssl_can_wr=n 2024.02.23 11:10:21 LOG3[0]: read_wants_read=Y, read_wants_write=n 2024.02.23 11:10:21 LOG3[0]: write_wants_read=n, write_wants_write=n 2024.02.23 11:10:21 LOG3[0]: shutdown_wants_read=n, shutdown_wants_write=n 2024.02.23 11:10:21 LOG3[0]: socket input buffer: 0 byte(s), TLS input buffer: 0 byte(s) 2024.02.23 11:10:21 LOG5[0]: Connection reset: 685 byte(s) sent to TLS, 381 byte(s) sent to socket 2024.02.23 11:10:21 LOG7[0]: remote_fd reset (FD=780) 2024.02.23 11:10:21 LOG7[0]: Remote descriptor (FD=780) closed 2024.02.23 11:10:21 LOG7[0]: local_rfd/local_wfd reset (FD=768) 2024.02.23 11:10:21 LOG7[0]: Local descriptor (FD=768) closed 2024.02.23 11:10:21 LOG7[0]: Service [oracle15211] finished (0 left) Any help is greatly appreciated! Thank you, Mark

1 0

Dynamic DNS
by alstar＠maybenot.work 20 Feb '24

20 Feb '24

Hi, I'm running Stunnel on Linux. It needs to connect to a dynamic IP address (by domain name). The DNS is updated automatically. I noticed that the last time the address changed, Stunnel stopped working. A ping from the machine produced the correct address but Stunnel was using the old one. Will a reload work?

4 6

stunnel 5.72 released
by Michał Trojnara 05 Feb '24

05 Feb '24

Dear Users, I have released version 5.72 of stunnel. ### Version 5.72, 2024.02.04, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 3.2.1. * Bugfixes - Fixed SSL_CTX_new() errors handling. - Fixed OPENSSL_NO_PSK builds. - Android build updated for NDK r23c. - stunnel.nsi updated for Debian 12. - Fixed tests with OpenSSL older than 1.0.2. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 3d532941281ae353319735144e4adb9ae489a10b7e309c58a48157f08f42e949 stunnel-5.72.tar.gz 1037c53f8ab590c2f3001e54cf381c3ea4225e9670b03870191383060e6851e7 stunnel-5.72-win64-installer.exe 668161b90034820198c456b4137ed3680d6fd49d4de920d51e499b84538f63d3 stunnel-5.72-android.zip Best regards, Mike

1 0