- stunnel-users - stunnel.org

Connection refused, then connects
by James Brown 17 May '19

17 May '19

Can anyone tell me why It tries ::1:25 first and fails before connecting to 127.0.0.1:25? 2019.05.17 13:48:34 LOG5[21]: Service [ssmtp465] accepted connection from ::ffff:192.168.1.76:49170 2019.05.17 13:48:34 LOG3[21]: s_connect: connect ::1:25: Connection refused (61) 2019.05.17 13:48:34 LOG5[21]: s_connect: connected 127.0.0.1:25 2019.05.17 13:48:34 LOG5[21]: Service [ssmtp465] connected remote server from 127.0.0.1:56701 /usr/local/etc/stunnel/stunnel.conf has: [ssmtp465] client = no accept = 465 connect = 25 options = NO_SSLv2 #transparent = source [ssmtp587] client = no accept = 587 connect = 127.0.0.1:25 options = NO_SSLv2 #transparent = source Not sure if this is relevant, but when I startup I get: 2019.05.17 12:45:27 LOG5[ui]: stunnel 5.53 on x86_64-apple-darwin18.5.0 platform 2019.05.17 12:45:27 LOG5[ui]: Compiled/running with OpenSSL 1.0.2r 26 Feb 2019 2019.05.17 12:45:27 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI 2019.05.17 12:45:27 LOG5[ui]: Reading configuration from file /usr/local/etc/stunnel/stunnel.conf 2019.05.17 12:45:27 LOG5[ui]: UTF-8 byte order mark detected 2019.05.17 12:45:27 LOG5[ui]: FIPS mode disabled 2019.05.17 12:45:27 LOG4[ui]: Insecure file permissions on /usr/local/etc/dovecot/mail.bordo.com.au.pem 2019.05.17 12:45:27 LOG4[ui]: Insecure file permissions on /usr/local/etc/dovecot/mail.bordo.com.au.pem 2019.05.17 12:45:27 LOG5[ui]: Configuration successful 2019.05.17 12:45:27 LOG5[ui]: Binding service [ssmtp465] to 0.0.0.0:465: Address already in use (48) 2019.05.17 12:45:27 LOG5[ui]: Binding service [ssmtp587] to 0.0.0.0:587: Address already in use (48) No idea what is already using those ports. Any suggestions? macOS 10.14.4 Thanks, James.

3 3

stunnel 5.54 released
by Michal Trojnara 15 May '19

15 May '19

Dear Users, I have released version 5.54 of stunnel. Version 5.54, 2019.05.15, urgency: LOW * New features - New "ticketKeySecret" and "ticketMacSecret" options to control confidentiality and integrity protection of the issued session tickets. These options allow for session resumption on other nodes in a cluster. - Added logging the list of active connections on SIGUSR2 or with Windows GUI. - Logging of the assigned bind address instead of the requested bind address. * Bugfixes - Service threads are terminated before OpenSSL cleanup to prevent occasional stunnel crashes at shutdown. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 5e8588a6c274b46b1d63e1b50f0725f4908dec736f6588eb48d1eb3d20c87902 stunnel-5.54.tar.gz ed8424731f7d6e0c9b11f4c7b597a072e558dae7979102d0b213759678079481 stunnel-5.54-win64-installer.exe 7659f605065e5155577a99abe1129dbc89523796196c8bf50d3fa9265ec34d93 stunnel-5.54-android.zip Best regards, Mike

1 0

Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Eric Eberhard 15 May '19

15 May '19

Killing anything will change the PID. If the PID needs to be constant a zombie is bad news! Zombies stink! E -----Original Message----- From: Jochen Bern [mailto:[email protected]] Sent: Wednesday, May 15, 2019 1:42 AM To: stunnel-users(a)stunnel.org Cc: Florian Lohoff <f(a)zz.de>; Eric Eberhard <flash(a)vicsmba.com> Subject: Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug? On 05/15/2019 12:22 AM, Florian Lohoff wrote: > On Tue, May 14, 2019 at 11:30:29AM -0700, Eric Eberhard wrote: >> That is not a bad idea. I'd wrap it in a C program so I could check >> if the pppd is alive and not a zombie. > > pppd is a pretty solid piece of software. Never seen it hang as a > zombie. A zombie process is *terminated* and, basically, just a remaining entry in the kernel's process table. It's not hanging around because of something its own code did wrong, but because its parent process fails to "reap" its child (first and foremost, collect its exit code from the kernel). Killing the parent cleans up zombies because the zombies get re-parented to the init / systemd process (PID 1), which then does the reaping. Regards, -- Jochen Bern Systemingenieur

1 0

Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Jochen Bern 15 May '19

15 May '19

On 05/15/2019 12:22 AM, Florian Lohoff wrote: > On Tue, May 14, 2019 at 11:30:29AM -0700, Eric Eberhard wrote: >> That is not a bad idea. I'd wrap it in a C program so I could check >> if the pppd is alive and not a zombie. > > pppd is a pretty solid piece of software. Never seen it hang as a > zombie. A zombie process is *terminated* and, basically, just a remaining entry in the kernel's process table. It's not hanging around because of something its own code did wrong, but because its parent process fails to "reap" its child (first and foremost, collect its exit code from the kernel). Killing the parent cleans up zombies because the zombies get re-parented to the init / systemd process (PID 1), which then does the reaping. Regards, -- Jochen Bern Systemingenieur

1 0

Re: [stunnel-users] Possible to verify client certificate BUT ignore expiration-date?
by Eric Eberhard 14 May '19

14 May '19

Use openssl to make a private cert? E -----Original Message----- From: stunnel-users [mailto:[email protected]] On Behalf Of Christopher Schultz Sent: Monday, May 13, 2019 2:28 PM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] Possible to verify client certificate BUT ignore expiration-date? All, Does anyone know if it is possible to perform all other verification of a client certificate EXCEPT allow the certificate to have expired? We have a vendor whose certificate has expired, and we want to allow their old certificate to work while they chase their tails trying to figure out the best way to re-issue a new cert for us. *eyeroll* Is it possible? Thanks, -chris

2 1

Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Eric Eberhard 14 May '19

14 May '19

Yes. Use inetd (or equivalent). Making an independent server work is difficult due to the problems like you are having. Inetd is in many O/S included and essential, others available. It always works. Always. Yes, there is a tiny amount of overhead for making connections. On an ancient AIX IBM I manage 2-4 million XML documents exchanged per day with no problems, all with inetd. Try it – save yourself some misery. Or maybe it won’t help at all except to add information :) E From: stunnel-users [mailto:[email protected]] On Behalf Of Martin Got Sent: Monday, May 13, 2019 9:08 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug? I'm trying to make stunnel wrapped ppp connection to achieve bidirectional data transfer over stunnel like shown below. Stunnel client --connect--> Stunnel server pppd client --connect--> pppd server 10.0.1.2 <--data--> 10.0.1.1 OpenBSD 6.4amd64 with Stunnel 5.44 server works till stunnel retries 'exec = pppd' section once stunnel client is reconnected. Also 'exec = pppd' section retries after a short network related communication lag also. Previous 'pppd' child instance haven't killed by stunnel 5.44 before new instance started. So second 'pppd' process started and runs simultaneously with the first 'pppd' and link down. Restarting Stunnel server can clear child 'pppd' processes. So newly reestablished 'pppd' link between 10.0.1.1 <--> 10.0.1.2 endpoints works till next interconnection. Does stunnel server have an option to start only one instance in 'exec' section or what should be done to fix this? Any suggestions highly appreciated. # ps -axu | grep pppd user 43231 0.0 0.0 476 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) user 39187 0.0 0.0 468 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) # tail -n 10 /var/log/daemon pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[43231] Using interface ppp1 pppd[43231] Connect: ppp0 <--> /dev/ttyp2 pppd[43231] Local IP address 10.0.1.1 pppd[43231] Remote IP address 10.0.1.2 pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[39187] Using interface ppp0 pppd[39187] Connect: ppp0 <--> /dev/ttyp5 pppd[39187] Couldn't set interface address: Address 10.0.1.1 or destination 10.0.1.2 already exists Stunnel configurations for server and client: 1. Server's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;socket = l:SO_LINGER=1:60 ; Session cache sessionCacheSize = 100 sessionCacheTimeout = 600 stack = 65536 TIMEOUTbusy = 600 TIMEOUTconnect = 10 TIMEOUTidle = 43200 TIMEOUTclose = 5 [ppp] accept = LOCAL-IP:PORT exec = /usr/sbin/pppd execargs = lock 10.0.1.1:10.0.1.2 local debug noauth ;execargs = lock passive 10.0.1.1:10.0.1.2 local debug noauth pty = yes CAfile = ca.crt cert = server.crt key = server.key verifyChain = yes 2. Stunnel client's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Session cache sessionCacheSize = 1 sessionCacheTimeout = 600 failover = rr [ppp] client = yes retry = yes connect = REMOTE-IP:PORT exec = /usr/sbin/pppd execargs = defaultroute persist lock passive 10.0.1.2:10.0.1.1 local debug noauth name ppp-client pty = yes CAfile = ca.crt cert = client.crt key = client.key verifyChain = yes checkHost = REMOTE-HOSTNAME ;checkIP = 1.2.3.4

2 1

Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Eric Eberhard 13 May '19

13 May '19

Sounds good. The inetd will handle the dropping of connections just fine ... but the below sounds like it would help even more. E -----Original Message----- From: stunnel-users [mailto:[email protected]] On Behalf Of Peter Pentchev Sent: Monday, May 13, 2019 2:16 PM To: Martin Got <martingot(a)protonmail.com> Cc: stunnel-users(a)stunnel.org Subject: Re: [stunnel-users] Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug? On Mon, May 13, 2019 at 04:07:57PM +0000, Martin Got wrote: > I'm trying to make stunnel wrapped ppp connection to achieve bidirectional data transfer over stunnel like shown below. > > Stunnel client --connect--> Stunnel server > pppd client --connect--> pppd server > 10.0.1.2 <--data--> 10.0.1.1 > > OpenBSD 6.4amd64 with Stunnel 5.44 server works till stunnel retries 'exec = pppd' section once stunnel client is reconnected. Also 'exec = pppd' section retries after a short network related communication lag also. Previous 'pppd' child instance haven't killed by stunnel 5.44 before new instance started. > > So second 'pppd' process started and runs simultaneously with the first 'pppd' and link down. Restarting Stunnel server can clear child 'pppd' processes. So newly reestablished 'pppd' link between 10.0.1.1 <--> 10.0.1.2 endpoints works till next interconnection. > > Does stunnel server have an option to start only one instance in 'exec' section or what should be done to fix this? Unfortunately, stunnel was not designed for your use case; it was designed to allow many different clients to make use of different instances of the same server program, one instance per client. You might try to do something else: if you really only have a single PPP client and you can really guarantee that anything that connects to stunnel must reuse the same connection, you could write a separate program that listens on a TCP port or on a local Unix socket, waits for the first connection, starts an instance of pppd, and then, from that point on, sends all the traffic from this instance to all the connections that it has received, even if a new connection appears before the old one has been torn down. Then you can point stunnel to the local Unix socket of that service, and anything that connects to stunnel will establish a new connection to your service, but it will not matter, since your service will be written in such a way as to send all the traffic to all the connections. So the service should do something like: 1. Create a local Unix socket and start listening on it. 2. Wait for the first connection. 3. Start an instance of pppd (at most one instance shall be running at any point in time) 4. Keep waiting for new connections; accept any and treat them all in the same way. 5. If any data comes from a remote connection, send it to pppd. 6. If any data comes from pppd, send it to *all* the remote connections. 7. If any of the remote connections is closed, well, so be it, good riddance, another one will come along presently (or maybe another one has already come along and has started talking to pppd through this service). 8. If the pppd child process dies, close all the remote connections and go back to step 2. Then you shall only have a problem if there are two "real" connections from different places at the same time - but if I understand your setup correctly, this should not really happen, since it is only you (your laptop or something like that) that connects to the PPP server. If you want, I could try to whip up some simple implementation of such a pseudo-multiplexer. G'luck, Peter -- Peter Pentchev roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

1 0

Possible to verify client certificate BUT ignore expiration-date?
by Christopher Schultz 13 May '19

13 May '19

All, Does anyone know if it is possible to perform all other verification of a client certificate EXCEPT allow the certificate to have expired? We have a vendor whose certificate has expired, and we want to allow their old certificate to work while they chase their tails trying to figure out the best way to re-issue a new cert for us. *eyeroll* Is it possible? Thanks, -chris

1 0

Stunnel 5.44 server side 'exec = pppd' runs second child 'pppd' process after reconnection. Bug?
by Martin Got 13 May '19

13 May '19

I'm trying to make stunnel wrapped ppp connection to achieve bidirectional data transfer over stunnel like shown below. Stunnel client --connect--> Stunnel server pppd client --connect--> pppd server 10.0.1.2 <--data--> 10.0.1.1 OpenBSD 6.4amd64 with Stunnel 5.44 server works till stunnel retries 'exec = pppd' section once stunnel client is reconnected. Also 'exec = pppd' section retries after a short network related communication lag also. Previous 'pppd' child instance haven't killed by stunnel 5.44 before new instance started. So second 'pppd' process started and runs simultaneously with the first 'pppd' and link down. Restarting Stunnel server can clear child 'pppd' processes. So newly reestablished 'pppd' link between 10.0.1.1 <--> 10.0.1.2 endpoints works till next interconnection. Does stunnel server have an option to start only one instance in 'exec' section or what should be done to fix this? Any suggestions highly appreciated. # ps -axu | grep pppd user 43231 0.0 0.0 476 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) user 39187 0.0 0.0 468 0:00.01 persist lock passive 10.0.1.1:10.0.1.2 local noauth (pppd) # tail -n 10 /var/log/daemon pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[43231] Using interface ppp1 pppd[43231] Connect: ppp0 <--> /dev/ttyp2 pppd[43231] Local IP address 10.0.1.1 pppd[43231] Remote IP address 10.0.1.2 pppd[39187] pppd 2.3.5 started by user, uid 0 pppd[39187] Using interface ppp0 pppd[39187] Connect: ppp0 <--> /dev/ttyp5 pppd[39187] Couldn't set interface address: Address 10.0.1.1 or destination 10.0.1.2 already exists Stunnel configurations for server and client: 1. Server's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;socket = l:SO_LINGER=1:60 ; Session cache sessionCacheSize = 100 sessionCacheTimeout = 600 stack = 65536 TIMEOUTbusy = 600 TIMEOUTconnect = 10 TIMEOUTidle = 43200 TIMEOUTclose = 5 [ppp] accept = LOCAL-IP:PORT exec = /usr/sbin/pppd execargs = lock 10.0.1.1:10.0.1.2 local debug noauth ;execargs = lock passive 10.0.1.1:10.0.1.2 local debug noauth pty = yes CAfile = ca.crt cert = server.crt key = server.key verifyChain = yes 2. Stunnel client's configuration ... foreground = yes debug = 7 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Session cache sessionCacheSize = 1 sessionCacheTimeout = 600 failover = rr [ppp] client = yes retry = yes connect = REMOTE-IP:PORT exec = /usr/sbin/pppd execargs = defaultroute persist lock passive 10.0.1.2:10.0.1.1 local debug noauth name ppp-client pty = yes CAfile = ca.crt cert = client.crt key = client.key verifyChain = yes checkHost = REMOTE-HOSTNAME ;checkIP = 1.2.3.4

2 1

Stunnel for O365 Sending Some Reports but not Others
by David Schmidt 10 May '19

10 May '19

Hello, We needed to reconfigure Stunnel for the SAP Business Objects server that sent email reports from G Suite over to a configuration that sends from an O365 account. The problem is that some of the reports work fine after the reconfiguration, while others always fail and I can't find out why and nothing has changed other than the mail settings. Microsoft doesn't even see the failed reports hitting their servers but when I look at Stunnel it seems like the TLS connection is being established correctly and I can see the connection being established from our firewall logs. I've attached the current O365 config as well as the old GSuite conifg, as well as logs of the debug output I see when I run a report that succeeds versus a report that fails. Can anyone give me an idea as to why Stunnel seems to be working to send out some reports but not others? Thank you, David Schmidt | Administrateur TI / IT Administrator | MTYGroup.com<http://mtygroup.com/> T+1 514-336-8885 Ext 8236 | C+1 514-708-7299 | 8210, route Transcanadienne, St. Laurent, QC, H4S 1M5 [http://mtygroup.com/signature/gif/use_this_left.gif]<http://mtygroup.com> [http://mtygroup.com/signature/gif/use_this_right.gif] <http://mtygroup.com> AVERTISSEMENT CONCERNANT LA CONFIDENTIALIT? / WARNING CONCERNING CONFIDENTIALITY Ce message peut contenir des informations confidentielles, privil?gi?es, et seulement pour ses destinataires. Si vous avez re?u ce message par erreur, veuillez en informer imm?diatement l'exp?diteur par retour de courriel et supprimer cette communication de votre syst?me. This email message may contain information that is confidential, privileged, and for communication only to its intended recipient or recipients. If you have received this message in error, please immediately notify the sender and delete the original message without making a copy.

1 0

Problem with stunnel 5.51
by Carter Browne 08 May '19

08 May '19

I received the following error trying to connect to a Windows host using RDP. I use stunnel as a connection point with secure messages coming in and then forwarded as secure messages going the desired end point. Stunnel is running on all three systems, the originator, the relay, and the destination. I have been using stunnel in this role for many years. As an additional point, 5.51 did work properly in the same role for secure telnet. The part of the log showing the failure is below. Thanks, Carter Before 2019.05.03 15:44:02 LOG5[ui]: stunnel 5.50 on armv7l-unknown-linux-gnueabihf platform 2019.05.03 15:44:02 LOG5[ui]: Compiled with OpenSSL 1.1.1a 20 Nov 2018 2019.05.03 15:44:02 LOG5[ui]: Running with OpenSSL 1.1.1b 26 Feb 2019 2019.05.03 15:44:02 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 2019.05.03 15:44:02 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2019.05.03 15:44:02 LOG5[ui]: UTF-8 byte order mark not detected 2019.05.03 15:44:02 LOG5[ui]: FIPS mode disabled 2019.05.03 15:44:52 LOG5[ui]: Configuration successful 2019.05.03 15:44:52 LOG5[ui]: Switched to chroot directory: /var/run/stunnel/ ... 2019.05.08 08:26:08 LOG5[980]: Service [c13alt-rdp] accepted connection from 192.168.179.22:63218 2019.05.08 08:26:09 LOG5[980]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-39, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 08:26:09 LOG5[981]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49180 2019.05.08 08:26:09 LOG5[980]: s_connect: connected 127.0.1.127:3389 2019.05.08 08:26:09 LOG5[981]: s_connect: connected 10.251.129.118:8001 2019.05.08 08:26:09 LOG5[981]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44796 2019.05.08 08:26:09 LOG5[980]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49180 2019.05.08 08:26:09 LOG5[981]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-13.cbcsnet.local, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 08:26:23 LOG5[980]: Connection closed: 1615 byte(s) sent to TLS, 1061 byte(s) sent to socket 2019.05.08 08:26:23 LOG5[981]: Connection closed: 1061 byte(s) sent to TLS, 1615 byte(s) sent to socket 2019.05.08 08:26:23 LOG5[982]: Service [c13alt-rdp] accepted connection from 192.168.179.22:63243 2019.05.08 08:26:23 LOG5[983]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49184 2019.05.08 08:26:23 LOG5[982]: s_connect: connected 127.0.1.127:3389 2019.05.08 08:26:23 LOG5[982]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49184 2019.05.08 08:26:23 LOG5[983]: s_connect: connected 10.251.129.118:8001 2019.05.08 08:26:23 LOG5[983]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44800 After 2019.05.08 12:50:18 LOG5[ui]: stunnel 5.51 on armv7l-unknown-linux-gnueabihf platform 2019.05.08 12:50:18 LOG5[ui]: Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 2019.05.08 12:50:18 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 2019.05.08 12:50:18 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2019.05.08 12:50:18 LOG5[ui]: UTF-8 byte order mark not detected 2019.05.08 12:50:18 LOG5[ui]: FIPS mode disabled 2019.05.08 12:50:42 LOG5[ui]: Configuration successful 2019.05.08 12:51:01 LOG5[2]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64139 2019.05.08 12:51:02 LOG5[2]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-39, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 12:51:02 LOG5[3]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49330 2019.05.08 12:51:02 LOG5[2]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:51:02 LOG5[2]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49330 2019.05.08 12:51:02 LOG5[3]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:51:02 LOG5[3]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44946 2019.05.08 12:51:02 LOG5[3]: Certificate accepted at depth=0: C=US, ST=Massachusetts, L=Winchester, O=CBCS, OU=MIS, CN=cbrowne-13.cbcsnet.local, emailAddress=cbrowne(a)cbcs-usa.com 2019.05.08 12:51:15 LOG5[2]: Connection closed: 1615 byte(s) sent to TLS, 1061 byte(s) sent to socket 2019.05.08 12:51:15 LOG5[3]: Connection closed: 1061 byte(s) sent to TLS, 1615 byte(s) sent to socket 2019.05.08 12:51:15 LOG5[4]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64141 2019.05.08 12:51:15 LOG5[5]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49334 2019.05.08 12:51:15 LOG5[4]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:51:15 LOG5[4]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49334 2019.05.08 12:51:15 LOG5[5]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:51:15 LOG5[5]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44950 2019.05.08 12:51:18 LOG3[4]: transfer() loop executes not transferring any data 2019.05.08 12:51:18 LOG3[4]: please report the problem to Michal.Trojnara(a)stunnel.org 2019.05.08 12:51:18 LOG3[4]: stunnel 5.51 on armv7l-unknown-linux-gnueabihf platform 2019.05.08 12:51:18 LOG3[4]: Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 2019.05.08 12:51:18 LOG3[4]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI 2019.05.08 12:51:18 LOG3[4]: protocol=TLSv1.2, SSL_pending=0 2019.05.08 12:51:18 LOG3[4]: sock_open_rd=Y, sock_open_wr=Y 2019.05.08 12:51:18 LOG3[4]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n 2019.05.08 12:51:18 LOG3[4]: sock_can_rd=n, sock_can_wr=n 2019.05.08 12:51:18 LOG3[4]: ssl_can_rd=n, ssl_can_wr=n 2019.05.08 12:51:18 LOG3[4]: read_wants_read=Y, read_wants_write=n 2019.05.08 12:51:18 LOG3[4]: write_wants_read=n, write_wants_write=n 2019.05.08 12:51:18 LOG3[4]: shutdown_wants_read=n, shutdown_wants_write=n 2019.05.08 12:51:18 LOG3[4]: socket input buffer: 0 byte(s), TLS input buffer: 0 byte(s) 2019.05.08 12:51:18 LOG5[4]: Connection reset: 2786 byte(s) sent to TLS, 5077 byte(s) sent to socket 2019.05.08 12:51:18 LOG5[5]: Connection closed: 5077 byte(s) sent to TLS, 2989 byte(s) sent to socket 2019.05.08 12:52:03 LOG5[6]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64144 2019.05.08 12:52:03 LOG5[6]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:52:03 LOG5[6]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49340 2019.05.08 12:52:03 LOG5[7]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49340 2019.05.08 12:52:03 LOG5[7]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:52:03 LOG5[7]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44956 2019.05.08 12:52:14 LOG5[6]: Connection closed: 1615 byte(s) sent to TLS, 1061 byte(s) sent to socket 2019.05.08 12:52:14 LOG5[7]: Connection closed: 1061 byte(s) sent to TLS, 1615 byte(s) sent to socket 2019.05.08 12:52:14 LOG5[8]: Service [c13alt-rdp] accepted connection from 192.168.179.22:64147 2019.05.08 12:52:14 LOG5[9]: Service [cbrowne-13-rdp] accepted connection from 127.0.0.1:49344 2019.05.08 12:52:14 LOG5[9]: s_connect: connected 10.251.129.118:8001 2019.05.08 12:52:14 LOG5[9]: Service [cbrowne-13-rdp] connected remote server from 10.251.129.84:44960 2019.05.08 12:52:14 LOG5[8]: s_connect: connected 127.0.1.127:3389 2019.05.08 12:52:14 LOG5[8]: Service [c13alt-rdp] connected remote server from 127.0.0.1:49344 2019.05.08 12:52:16 LOG3[8]: transfer() loop executes not transferring any data 2019.05.08 12:52:16 LOG3[8]: please report the problem to Michal.Trojnara(a)stunnel.org

2 2

Automatic stunnel-client reconnect and keep initial session
by Martin Got 01 May '19

01 May '19

Which commands to stunnel can perform keeping session ID in case of stunnel-client reconnection? Do I add commands to both stunnel-client and stunnel-server to keep the initial session?

1 0

Keep initial session-ID when stunnel-client reconnect to a stunnel-server
by Martin Got 01 May '19

01 May '19

Trying to establish link using pppd connection overlapped into stunnel 5.44. Server runs on OpenBSD 6.4, client uses the same stunnel and OS versions. From the client's side I have to reconnect to stunnel-server in case of Internet link is dropped. And expecting that pppd session is kept by stunnel over reconnections possible. But stunnel-server runs another pppd instance when stunnel-client reconnects. After reconnection in system processes I see two pppd processes (as shows below), and pppd link has no pings after it. # ps -aux | grep pppd user 45359 0.0 0.0 440 1672 ?? I Tue11PM 0:00.01 lock passive 10.0.1.1:10.0.1.2 local debug noauth (pppd) user 1156 0.0 0.0 321 1210 ?? I Tue12PM 0:00.01 lock passive 10.0.1.1:10.0.1.2 local debug noauth (pppd) 1. The question is how to keep initial session established by stunnel-client and do not run second pppd process by stunnel-server? 2. May I keep session by cache-ID on the client's side only or do I need to do it on both client and server? Can it help not to run another pppd process? Both server config and client config parts are below: # cat /etc/stunnel/stunnel-server.conf ... [ppp] ;SERVER accept 1.2.3.4:443 exec = /usr/sbin/pppd execargs = lock passive 10.0.1.1:10.0.1.2 local debug noauth pty = yes CAfile = ca.crt cert = server.crt key = server.key verifyChain = yes TIMEOUTclose = 0 ... # cat /etc/stunnel/stunnel-client.conf ... [ppp] ;CLIENT client = yes retry = yes connect = 1.2.3.4:443 exec = /usr/sbin/pppd execargs = persist lock 10.0.1.2:10.0.1.1 local debug noauth name ppp-client pty = yes CAfile = ca.crt cert = client.crt key = client.key verifyChain = yes checkHost = hostname ;checkIP = 1.2.3.4 ... Thank you for answer in advance.

1 0

Re: [stunnel-users] illegal instruction crash 5.50 Debian/Stretch
by Michal Trojnara 29 Apr '19

29 Apr '19

On 24.04.2019 16:06, Florian Lohoff wrote: > with the stunnel4 in Debian/Stretch i am experiencing pretty regular > crashes with illegal instruction. Version is 5.50. > In Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880659 > you can see the drill down to a Lock beeing unlocked although > not locked. When i look at the code its some usage of openssl > primitives. (Unlock happens in openssl code) > I had a quick look at the changelog and this: > "Service threads are terminated before OpenSSL cleanup to prevent occasional stunnel crashes at shutdown." > sounds a bit like the issue i am experiencing. > Can you confirm this? Yes, I do confirm this is the issue described in the Debian bug #880659. It wasn't a simple coding error, but rather a design flaw introduced in version 3.0 that took 20 years to identify and fix. Before version 5.18, released almost 4 years ago, the shutdown race condition mostly manifested itself while terminating stunnel under extremely heavy load, such as stress testing. The probability has increased with the introduction of periodic DH parameter regeneration in version 5.18. I didn't test it, but I suspect some changes in the OpenSSL internals may have also cause the crashes to only surface fairly recently, and not 20 years ago. The fix itself involves a major redesign of the stunnel threading subsystem, so I made a beta version and I'd appreciate your help with testing it: https://www.stunnel.org/downloads/beta/stunnel-5.54b2.tar.gz Best regards, Mike

2 1

Either "verifyChain" or "verifyPeer" has to be enabled
by kovacs janos 23 Apr '19

23 Apr '19

sorry to bother, again this is probably something simple, but i couldn't find anything about it. i'm trying to make stunnel NOT verify the certificate of the address it connects to. specifically because the certificate date will give an error, and i know its safe to connect there. whenever i put 'verify = 0' or 'verifyChain = no' or 'verifyPeer = no' in the configuration, i get an error saying 'Either "verifyChain" or "verifyPeer" has to be enabled', and so the configuration can't be applied. and i found nothing about this anywhere. or this could only be set on server Services? and there is no way to not verify if 'client = yes'?

1 0

Stunnel 5.44 client syntax to accept connections on pty?
by Martin Got 18 Apr '19

18 Apr '19

How to use 'stunnel' in client mode to accept connections on pty from local programs like 'ppp' instead of 'accept=IP:PORT'? 'pty = yes' seems work in server mode only, so when I removed 'accept = 127.0.0.1:1723' from 'stunnel' client config I'm getting the error: [!] Service [ppp]: Each service must define two endpoints on stunnel-5.44 I need to call 'stunnel' client from 'pppd' and communicate with 'stunnel' using pty if it was possible by using a command: pppd /dev/ptyp3 10.0.1.2: local debug noauth passive noccp novj novjccomp nopcomp noaccomp name ppp-client connect 'stunnel /etc/stunnel/stunnel-client.conf' Both 'pppd' and 'stunnel' started by executing the command above, but 'pppd' can't communicate to 'stunnel' server using pty. Please advice. [ppp] client = yes accept = [127.0.0.1:1723 ](http://127.0.0.1:1723) ^^^^^^^^^^^^^^^^^^^^^^^ connect = STUNNEL-SERVER-IP:723 CAfile = /etc/stunnel/ca.crt cert = /etc/stunnel/client.crt key = /etc/stunnel/client.key verifyChain = yes checkHost = hostna.me ;checkIP = 1.2.3.4

2 1

Sending original IP (proxy) for smtp
by James Brown 16 Apr '19

16 Apr '19

I’d like stunnel to pass the incoming IP along, not stunnel's IP. My traffic flow is: Stunnel (accept on port 465) -> ASSP (an smtp proxy) -> Postfix (accept on port 10026) I tried: [ssmtp] client = no accept = 465 connect = 25 protocol = proxy But ASSP had: Apr-15-19 18:50:22 [Worker_1] Connected: session:7FE104AA1870 127.0.0.1:58954 > 127.0.0.1:25 > 127.0.0.1:10026 Apr-15-19 18:50:23 [Worker_1] 127.0.0.1 warning: got reply '502 5.5.2 Error: command not recognized' from 127.0.0.1 Apr-15-19 18:50:23 id-18223-03317 [Worker_1] 127.0.0.1 info: sending EHLO instead of HELO to 127.0.0.1 Apr-15-19 18:50:23 id-18223-03317 [Worker_1] 127.0.0.1 disconnected: session:7FE104AA1870 127.0.0.1 - processing time 1 seconds And Postfix had: 2019-04-15 18:50:22.995042+1000 localhost smtpd[33360]: connect from localhost[127.0.0.1] 2019-04-15 18:50:23.108756+1000 localhost smtpd[33360]: improper command pipelining after EHLO from localhost[127.0.0.1]: RSET\r\n 2019-04-15 18:50:23.273664+1000 localhost smtpd[33360]: disconnect from localhost[127.0.0.1] ehlo=2 rset=1 quit=1 unknown=0/1 commands=4/5 So I take it protocol=proxy is not the way to do it. Sounds like this only works with haproxy which I do not have installed. Is there a way to do this? The problem I am trying to solve is ASSP has lines like: warning: SMTP authentication failed on 127.0.0.1 - obviously I don’t want fail2ban to ban 127.0.0.1. Stunnel log has: 2019.04.15 18:52:26 LOG5[23]: Service [ssmtp] accepted connection from ::ffff:185.222.209.66:53642 2019.04.15 18:52:27 LOG3[23]: s_connect: connect ::1:25: Connection refused (61) Any suggestions? Thanks, James.

2 3

Support for TLS 1.3 Early Data?
by hshh 13 Apr '19

13 Apr '19

Is it stunnel 5.54 support for TLS 1.3 Early Data? Stunnel 5.54, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384. I was tested by openssl s_client, return "Early data was not sent".

1 0

Possible memory leak at asn1_lib.c:412: 20417 allocations
by Marc Smith 12 Apr '19

12 Apr '19

Hi, I'm using stunnel version 5.44 with OpenSSL version 1.0.2r on Linux. I noticed if stunnel has been running for a while, we start observing these messages in the logs: Apr 12 19:12:11 localhost stunnel: LOG4[971]: Possible memory leak at asn1_lib.c:412: 20417 allocations Apr 12 19:12:11 localhost stunnel: LOG4[971]: Possible memory leak at tasn_new.c:180: 20416 allocations And indeed, the process is consuming memory at a steady rate, and continues to grow until stopped. I updated to the latest stunnel version (5.53) and I no longer see these "possible memory leak" messages in the logs, yet the process still appears to consume memory as before (until it gets very large and things stop working). Is this actually a bug in the OpenSSL library? I'm using the latest in that release series (1.0.2), but perhaps this is a "known" leak and resolved in OpenSSL 1.1.1? Any help would be greatly appreciated. Thanks, Marc

1 0

OCSP validation via AIA responders through a proxy
by Olops, Daniel 12 Apr '19

12 Apr '19

Hello, stunnel v5.53 ignores proxy settings when performing OCSP validation via AIA responders. An open issue for OpenSSL at their GitHub suggests that this is a feature request for them (https://github.com/openssl/openssl/issues/6965) thus not being a stunnel limitation itself, and I've asked for clarification in the openssl-users mainling list (https://mta.openssl.org/pipermail/openssl-users/2019-April/010285.html) In either case, I want do double-check it with you guys: is this really an OpenSSL limitation, or is this something that can be addressed in stunnel code? Regards, Daniel O. Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284 Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705

1 0

stunnel 5.44 + pppd client side problem
by Martin Got 12 Apr '19

12 Apr '19

Trying to set up pppd link with stunnel wrapped between two OpenBSD 6.4amd64 machines. I use this reference article as an idea: http://bremford.org/tips/QuickStunnelVPN.html While connecting from client's side by command: /usr/sbin/pppd ptypA 10.0.1.2: local debug noauth passive noccp novj novjccomp nopcomp noaccomp name ppp-clnt connect 'stunnel /etc/stunnel/stunnel-client.conf stunnel-client starts, pppd starts on client's end according to stunnel-clnt.log, but has LCP timeouts: # tail stunnel-clnt.log stunnel: LOG5[ui]: Configuration successful pppd[5421]: Connect: ppp2 <--> /dev/ptypA pppd[5421]: LCP: timeout sending Config-Requests pppd[5421]: Connection terminated. pppd[5421]: Connect script failed It seems no pppd pty client connection to stunnel-local nor remote stunnel-server afterwards. But when I tried to connect to stunnel-client port 1723 using telnet: telnet localhost 1723 I received pppd advertisements from remote stunnel-server. It seems exec = /usr/sbin/pppd on stunnel-server is running when client's stunnel-client connection appeared. Can it be a problem with pppd and stunnel-client using pty? Please advice. # cat /etc/stunnel/stunnel-server.conf ;chroot = /var/stunnel # chroot is disabled for testing ;setuid = _stunnel # stunnel started by root for testing currently ;setgid = _stunnel ; PID file is created inside the chroot jail (if enabled) ;pid = /stunnel.pid foreground = yes debug = 7 ;output = log/stunnel.log # disabled sslVersion = TLSv1.2 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Enable support for the insecure SSLv3 protocol ;options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 ; Fix for Eudora "error reading network" can be useful for changing packet length options = DONT_INSERT_EMPTY_FRAGMENTS ; These options provide additional security at some performance degradation ;options = SINGLE_ECDH_USE ;options = SINGLE_DH_USE ; *** TLS server mode services [ppp] accept = 723 exec = /usr/sbin/pppd execargs = 10.0.1.1: local debug noauth pty = yes CAfile = /etc/stunnel/ca.crt cert = /etc/stunnel/srv.crt key = /etc/stunnel/private/srv.key verifyChain = yes TIMEOUTclose = 45 [default] ; HTTP connections ;ciphers = ALL ;options = CIPHER_SERVER_PREFERENCE accept = 1111 connect = 127.0.0.1:80 CAfile = /etc/stunnel/ca.crt cert = /etc/stunnel/srv.crt key = /etc/stunnel/private/srv.key verifyChain = yes TIMEOUTclose = 0 [ntp] connect = 127.0.0.1:123 sni = default:ntp CAfile = /etc/stunnel/ca.crt cert = /etc/stunnel/srv.crt key = /etc/stunnel/private/srv.key verifyChain = yes TIMEOUTclose = 0 -------------------- # cat /etc/stunnel/stunnel-client.conf chroot = /var/stunnel setuid = _stunnel setgid = _stunnel pid = /stunnel-clnt.pid foreground = yes debug = 7 ;output = log/stunnel-clnt.log sslVersion = TLSv1.2 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Enable support for the insecure SSLv3 protocol ;options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 ; Fix for Eudora "error reading network" can be useful for changing packet length options = DONT_INSERT_EMPTY_FRAGMENTS ; These options provide additional security at some performance degradation ;options = SINGLE_ECDH_USE ;options = SINGLE_DH_USE [ppp] client = yes accept = 127.0.0.1:1723 # 'accept' is absent in client's configuration http://bremford.org/tips/QuickStunnelVPN.htmlbut stunnel reports: [!] Service [ppp]: Each service must define two endpoints on stunnel-5.44 connect = STUNNEL-SERVER-IP:723 CAfile = /etc/stunnel/ca.crt cert = /etc/stunnel/client.crt key = /etc/stunnel/client.key verifyChain = yes checkHost = hostna.me ;checkIP = 1.2.3.4 --------------------

2 1

Stunnel 5.51 Pop3 Problem?
by Colin 10 Apr '19

10 Apr '19

Hello, I'm new to this list and looking for advice/help with release 5.51 for Windows. I have three accounts, Yahoo, Aol and Gmx and I use Foxmail 5 with Stunnel. I use pop3 with all accounts and sometimes when retrieving mail I may decide to 'Not Fetch' any mail on the server that looks 'iffy' untill I've looked at it via the mail providers website. Now I've just upgraded to version 5.51 (over 5.50) and when checking any of the said accounts I can't see any mail that hasn't been fetched (the server looks empty.) But if I login to the mail website the unfetched mail is there to view for all accounts. I reverted to version 5.50 and now I can see the unfetched mail for all accounts in my 3rd party software. Therefore my question is: Is there a problem (bug??) with 5.51 which stops me from seeing unfetched pop3 mail or do I have to add something to the config file to make it work properly? Thanks...Colin ============ The problem of mail not being seen on the server seems fixed in 5.52 but now another glitch has arisen. When trying to download mail from a server the programme keeps freezing at a certain point. Let's say if I have ten mails to download the programme will freeze at maybe the third one and won't download the rest. I can try it several times and everything freezes at the same point. Again I've gone back to 5.50 and all works perfectly. Any ideas on how to fix this or shall I stay with 5.50?

2 1

Connection issues after upgrading to 5.51 (macOS)
by Dennis Preiser 10 Apr '19

10 Apr '19

Hi, I have been using stunnel for quite a long time on macOS without any problems. Specifically, I use this to connect to an nntps server. This is the corresponding config section: | [nntp2] | client = yes | accept = 127.0.0.2:1119 | connect = news.individual.de:563 With 5.50 everything goes well: | 2019.04.06 10:48:05 LOG5[2]: Service [nntp2] accepted connection from 127.0.0.2:49366 | 2019.04.06 10:48:05 LOG5[2]: s_connect: connected 130.133.4.10:563 | 2019.04.06 10:48:05 LOG5[2]: Service [nntp2] connected remote server from 192.168.200.102:49367 I can read news without further log entries. After the upgrade to 5.51 I can not read any news anymore. As soon as I want to read an article the connection breaks down: | 2019.04.06 10:54:09 LOG5[0]: Service [nntp2] accepted connection from 127.0.0.2:49189 | 2019.04.06 10:54:09 LOG5[0]: s_connect: connected 130.133.4.10:563 | 2019.04.06 10:54:09 LOG5[0]: Service [nntp2] connected remote server from 192.168.200.102:49190 | 2019.04.06 10:54:19 LOG3[0]: transfer() loop executes not transferring any data | 2019.04.06 10:54:19 LOG3[0]: please report the problem to Michal.Trojnara(a)stunnel.org | 2019.04.06 10:54:19 LOG3[0]: stunnel 5.51 on x86_64-apple-darwin18.5.0 platform | 2019.04.06 10:54:19 LOG3[0]: Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 | 2019.04.06 10:54:19 LOG3[0]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI | 2019.04.06 10:54:19 LOG3[0]: protocol=TLSv1.2, SSL_pending=0 | 2019.04.06 10:54:19 LOG3[0]: sock_open_rd=Y, sock_open_wr=Y | 2019.04.06 10:54:19 LOG3[0]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n | 2019.04.06 10:54:19 LOG3[0]: sock_can_rd=n, sock_can_wr=n | 2019.04.06 10:54:19 LOG3[0]: ssl_can_rd=n, ssl_can_wr=n | 2019.04.06 10:54:19 LOG3[0]: read_wants_read=Y, read_wants_write=n | 2019.04.06 10:54:19 LOG3[0]: write_wants_read=n, write_wants_write=n | 2019.04.06 10:54:19 LOG3[0]: shutdown_wants_read=n, shutdown_wants_write=n | 2019.04.06 10:54:19 LOG3[0]: socket input buffer: 0 byte(s), TLS input buffer: 0 byte(s) | 2019.04.06 10:54:19 LOG5[0]: Connection reset: 2151 byte(s) sent to TLS, 3546 byte(s) sent to socket | 2019.04.06 10:54:21 LOG5[1]: Service [nntp2] accepted connection from 127.0.0.2:49191 | 2019.04.06 10:54:21 LOG5[1]: s_connect: connected 130.133.4.10:563 | 2019.04.06 10:54:21 LOG5[1]: Service [nntp2] connected remote server from 192.168.200.102:49192 | 2019.04.06 10:54:23 LOG3[1]: transfer() loop executes not transferring any data | 2019.04.06 10:54:23 LOG3[1]: please report the problem to Michal.Trojnara(a)stunnel.org | 2019.04.06 10:54:23 LOG3[1]: stunnel 5.51 on x86_64-apple-darwin18.5.0 platform | 2019.04.06 10:54:23 LOG3[1]: Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 | 2019.04.06 10:54:23 LOG3[1]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI | 2019.04.06 10:54:23 LOG3[1]: protocol=TLSv1.2, SSL_pending=0 | 2019.04.06 10:54:23 LOG3[1]: sock_open_rd=Y, sock_open_wr=Y | 2019.04.06 10:54:23 LOG3[1]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n | 2019.04.06 10:54:23 LOG3[1]: sock_can_rd=n, sock_can_wr=n | 2019.04.06 10:54:23 LOG3[1]: ssl_can_rd=n, ssl_can_wr=n | 2019.04.06 10:54:23 LOG3[1]: read_wants_read=Y, read_wants_write=n | 2019.04.06 10:54:23 LOG3[1]: write_wants_read=n, write_wants_write=n | 2019.04.06 10:54:23 LOG3[1]: shutdown_wants_read=n, shutdown_wants_write=n | 2019.04.06 10:54:23 LOG3[1]: socket input buffer: 0 byte(s), TLS input buffer: 0 byte(s) | 2019.04.06 10:54:23 LOG5[1]: Connection reset: 163 byte(s) sent to TLS, 435 byte(s) sent to socket Downgrading to 5.50 solves this issue for the time being. Are there any changes between 5.50 and 5.51 that could explain this behavior? Dennis

1 1

stunnel 5.53 released
by Michal Trojnara 10 Apr '19

10 Apr '19

Dear Users, I have released version 5.53 of stunnel. Version 5.53, 2019.04.10, urgency: HIGH * Bugfixes - Fixed data transfer stalls introduced in stunnel 5.51. * New features - Android binary updated to support Android 4.x. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 80439896ee14269eb70bc8bc669433c7d619018a62c9f9c5c760a24515302585 stunnel-5.53.tar.gz 4f2d24d08f547943b8a499d411425409a52973a349c9120c650ba77d3f29ef79 stunnel-5.53-win64-installer.exe e619880f4fc25a7a4869cace9f6e6f3f5940cfdb764ed9987d892d9e9b0ea35d stunnel-5.53-android.zip Best regards, Mike

1 0

stunnel 5.52 released
by Michal Trojnara 10 Apr '19

10 Apr '19

Dear Users, I have released version 5.52 of stunnel. Version 5.52, 2019.04.08, urgency: HIGH * Bugfixes - Fixed a transfer() loop bug introduced in stunnel 5.51. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 00b973aa0d48b0707dd722c4e0a20b8378fc9b0ba301fdb785ffb75341024e21 stunnel-5.52.tar.gz c9224c35cdd3a6de8fab7c2844ca0c185ebcc96fd9183a05407e2ba77cadc7c6 stunnel-5.52-win64-installer.exe d4ff581e1547c2e194abd586e9542bfe20399c1287f970eaa5ba1824e4567453 stunnel-5.52-android.zip Best regards, Mike

2 1