- 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

stunnel 5.51 released
by Michal Trojnara 10 Apr '19

10 Apr '19

Dear Users, I have released version 5.51 of stunnel. Version 5.51, 2019.04.04, urgency: MEDIUM * New features - Hexadecimal PSK keys are automatically converted to binary. - Session ticket support (requires OpenSSL 1.1.1 or later). "connect" address persistence is currently unsupported with session tickets. - SMTP HELO before authentication (thx to Jacopo Giudici). - New "curves" option to control the list of elliptic curves in OpenSSL 1.1.0 and later. - New "ciphersuites" option to control the list of permitted TLS 1.3 ciphersuites. - Include file name and line number in OpenSSL errors. - Compatibility with the current OpenSSL 3.0.0-dev branch. - Better performance with SSL_set_read_ahead()/SSL_pending(). * Bugfixes - Fixed PSKsecrets as a global option (thx to Teodor Robas). - Fixed a memory allocation bug (thx to matanfih). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 77437cdd1aef1a621824bb3607e966534642fe90c69f4d2279a9da9fa36c3253 stunnel-5.51.tar.gz a0e26fde3ba09d6545cfbb44cab06ebd4ddf9c4b536e7d8eb76615ab54b2339c stunnel-5.51-win64-installer.exe ee90bef40cb47617fe7372707dba119f5176cb0fd9eb1bc00cdd1e2c370041db stunnel-5.51-android.zip Best regards, Mike

2 1

Problems after compiling stunnel 5.16 with openssl 1.0.2k
by simona vittori 09 Apr '19

09 Apr '19

Hello, I have compiled stunnel 5.16 with openssl 1.0.2k on a linux 3.0.101-97-default. When I execute ./stunnel -version I receive the following error: ./stunnel: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory Can anyone help me please? Thanks a lot bye bye Simona

2 1

Issues after upgrading stunnel to v5.51 on Windows
by stunnel＠alpiston.com 07 Apr '19

07 Apr '19

Hello, I've been using stunnel v5.50 (x64-pc-mingw32-gnu) to encrypt RTSP traffic between two Win10 Pro computers without any problems. However, after upgrading to stunnel v5.51 the RTSP traffic has started to stutter (as the framerate has dropped to almost nothing, from 20 fps to 0.01 fps to be precise), and the few frames that are actually transferred arrive visually corrupted. After enabling debugging at level 7, I get the following (some parts have been obfuscated for privacy reasons): 2019.04.08 00:53:51 LOG7[main]: Found 1 ready file descriptor(s) 2019.04.08 00:53:51 LOG7[main]: FD=528 ifds=r-x ofds=--- 2019.04.08 00:53:51 LOG7[main]: FD=536 ifds=r-x ofds=--- 2019.04.08 00:53:51 LOG7[main]: FD=544 ifds=r-x ofds=--- 2019.04.08 00:53:51 LOG7[main]: FD=648 ifds=r-x ofds=r-- 2019.04.08 00:53:51 LOG7[main]: FD=664 ifds=r-x ofds=--- 2019.04.08 00:53:51 LOG7[main]: FD=828 ifds=r-x ofds=--- 2019.04.08 00:53:51 LOG7[main]: Service [RTSP] accepted (FD=584) from A.B.C.D:E 2019.04.08 00:53:51 LOG7[main]: Creating a new thread 2019.04.08 00:53:51 LOG7[main]: New thread created 2019.04.08 00:53:51 LOG7[2]: Service [RTSP] started 2019.04.08 00:53:51 LOG7[2]: Setting local socket options (FD=584) 2019.04.08 00:53:51 LOG7[2]: Option TCP_NODELAY set on local socket 2019.04.08 00:53:51 LOG5[2]: Service [RTSP] accepted connection from A.B.C.D:E 2019.04.08 00:53:51 LOG6[2]: s_connect: connecting F.G.H.I:J 2019.04.08 00:53:51 LOG7[2]: s_connect: s_poll_wait F.G.H.I:J: waiting 10 seconds 2019.04.08 00:53:51 LOG5[2]: s_connect: connected F.G.H.I:J 2019.04.08 00:53:51 LOG5[2]: Service [RTSP] connected remote server from A.B.C.D:K 2019.04.08 00:53:51 LOG7[2]: Setting remote socket options (FD=900) 2019.04.08 00:53:51 LOG7[2]: Option TCP_NODELAY set on remote socket 2019.04.08 00:53:51 LOG7[2]: Remote descriptor (FD=900) initialized 2019.04.08 00:53:51 LOG6[2]: SNI: sending servername: LLLL 2019.04.08 00:53:51 LOG6[2]: Peer certificate required 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): before SSL initialization 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS write client hello 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS write client hello 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS read server hello 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): TLSv1.3 read encrypted extensions 2019.04.08 00:53:51 LOG7[2]: Verification started at depth=1: O=O, OU=OU, CN=CN 2019.04.08 00:53:51 LOG7[2]: CERT: Pre-verification succeeded 2019.04.08 00:53:51 LOG6[2]: Certificate accepted at depth=1: O=O, OU=OU, CN=CN 2019.04.08 00:53:51 LOG7[2]: Verification started at depth=0: O=O, OU=OU 2019.04.08 00:53:51 LOG7[2]: CERT: Pre-verification succeeded 2019.04.08 00:53:51 LOG6[2]: CERT: Host name "LLLL" matched with "LLLL" 2019.04.08 00:53:51 LOG5[2]: Certificate accepted at depth=0: O=O, OU=OU 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS read server certificate 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): TLSv1.3 read server certificate verify 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS read finished 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS write change cipher spec 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS write finished 2019.04.08 00:53:51 LOG7[2]: 1 client connect(s) requested 2019.04.08 00:53:51 LOG7[2]: 1 client connect(s) succeeded 2019.04.08 00:53:51 LOG7[2]: 0 client renegotiation(s) requested 2019.04.08 00:53:51 LOG7[2]: 0 session reuse(s) 2019.04.08 00:53:51 LOG6[2]: TLS connected: new session negotiated 2019.04.08 00:53:51 LOG6[2]: TLSv1.3 ciphersuite: TLS_CHACHA20_POLY1305_SHA256 (256-bit encryption) 2019.04.08 00:53:51 LOG7[2]: Compression: null, expansion: null 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSL negotiation finished successfully 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSL negotiation finished successfully 2019.04.08 00:53:51 LOG7[2]: Deallocating application specific data for session connect address 2019.04.08 00:53:51 LOG7[2]: New session callback 2019.04.08 00:53:51 LOG7[2]: Peer certificate was cached (1509 bytes) 2019.04.08 00:53:51 LOG6[2]: Session id: 08B6A892F03C33D29542A794B1C5B0A7646FB9160318EC39D3F294EEF7CAE4EB 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS read server session ticket 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSL negotiation finished successfully 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSL negotiation finished successfully 2019.04.08 00:53:51 LOG7[2]: New session callback 2019.04.08 00:53:51 LOG7[2]: Deallocating application specific data for session connect address 2019.04.08 00:53:51 LOG6[2]: Session id: 9A06F5437D7039A32E531DA4976EDE9F8CA44820025221D1CE36E237B71E9AD3 2019.04.08 00:53:51 LOG7[2]: TLS state (connect): SSLv3/TLS read server session ticket 2019.04.08 00:54:02 LOG6[2]: Read socket closed (readsocket) 2019.04.08 00:54:02 LOG7[2]: Sending close_notify alert 2019.04.08 00:54:02 LOG7[2]: TLS alert (write): warning: close notify 2019.04.08 00:54:02 LOG6[2]: SSL_shutdown successfully sent close_notify alert 2019.04.08 00:54:02 LOG7[main]: Found 1 ready file descriptor(s) 2019.04.08 00:54:02 LOG7[main]: FD=528 ifds=r-x ofds=--- 2019.04.08 00:54:02 LOG7[main]: FD=536 ifds=r-x ofds=--- 2019.04.08 00:54:02 LOG7[main]: FD=544 ifds=r-x ofds=--- 2019.04.08 00:54:02 LOG7[main]: FD=648 ifds=r-x ofds=r-- 2019.04.08 00:54:02 LOG7[main]: FD=664 ifds=r-x ofds=--- 2019.04.08 00:54:02 LOG7[main]: FD=828 ifds=r-x ofds=--- 2019.04.08 00:54:02 LOG7[main]: Service [RTSP] accepted (FD=908) from A.B.C.D:L 2019.04.08 00:54:02 LOG7[main]: Creating a new thread 2019.04.08 00:54:02 LOG7[main]: New thread created 2019.04.08 00:54:02 LOG7[3]: Service [RTSP] started 2019.04.08 00:54:02 LOG7[3]: Setting local socket options (FD=908) 2019.04.08 00:54:02 LOG7[3]: Option TCP_NODELAY set on local socket 2019.04.08 00:54:02 LOG5[3]: Service [RTSP] accepted connection from A.B.C.D:L 2019.04.08 00:54:02 LOG7[2]: TLS alert (read): warning: close notify 2019.04.08 00:54:02 LOG6[2]: TLS closed (SSL_read) 2019.04.08 00:54:02 LOG7[2]: Sent socket write shutdown 2019.04.08 00:54:02 LOG5[2]: Connection closed: 1374 byte(s) sent to TLS, 1782 byte(s) sent to socket 2019.04.08 00:54:02 LOG7[2]: Remote descriptor (FD=900) closed 2019.04.08 00:54:02 LOG7[2]: Local descriptor (FD=584) closed 2019.04.08 00:54:02 LOG7[2]: Service [RTSP] finished (1 left) 2019.04.08 00:54:02 LOG6[3]: s_connect: connecting F.G.H.I:J 2019.04.08 00:54:02 LOG7[3]: s_connect: s_poll_wait F.G.H.I:J: waiting 10 seconds 2019.04.08 00:54:02 LOG5[3]: s_connect: connected F.G.H.I:J 2019.04.08 00:54:02 LOG5[3]: Service [RTSP] connected remote server from A.B.C.D:M 2019.04.08 00:54:02 LOG7[3]: Setting remote socket options (FD=592) 2019.04.08 00:54:02 LOG7[3]: Option TCP_NODELAY set on remote socket 2019.04.08 00:54:02 LOG7[3]: Remote descriptor (FD=592) initialized 2019.04.08 00:54:02 LOG6[3]: SNI: sending servername: LLLL 2019.04.08 00:54:02 LOG6[3]: Peer certificate required 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): before SSL initialization 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSLv3/TLS write client hello 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSLv3/TLS write client hello 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSLv3/TLS read server hello 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): TLSv1.3 read encrypted extensions 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSLv3/TLS read finished 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSLv3/TLS write change cipher spec 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSLv3/TLS write finished 2019.04.08 00:54:02 LOG7[3]: Remove session callback 2019.04.08 00:54:02 LOG7[3]: 2 client connect(s) requested 2019.04.08 00:54:02 LOG7[3]: 2 client connect(s) succeeded 2019.04.08 00:54:02 LOG7[3]: 0 client renegotiation(s) requested 2019.04.08 00:54:02 LOG7[3]: 1 session reuse(s) 2019.04.08 00:54:02 LOG6[3]: TLS connected: previous session reused 2019.04.08 00:54:02 LOG6[3]: TLSv1.3 ciphersuite: TLS_CHACHA20_POLY1305_SHA256 (256-bit encryption) 2019.04.08 00:54:02 LOG7[3]: Compression: null, expansion: null 2019.04.08 00:54:02 LOG6[3]: Session id: 9A06F5437D7039A32E531DA4976EDE9F8CA44820025221D1CE36E237B71E9AD3 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSL negotiation finished successfully 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSL negotiation finished successfully 2019.04.08 00:54:02 LOG7[3]: New session callback 2019.04.08 00:54:02 LOG7[3]: Deallocating application specific data for session connect address 2019.04.08 00:54:02 LOG6[3]: Session id: C0F06C6E894812890045433304AD5880C6512D9FD3E61AA67285009143AFD645 2019.04.08 00:54:02 LOG7[3]: TLS state (connect): SSLv3/TLS read server session ticket 2019.04.08 00:54:05 LOG3[3]: transfer() loop executes not transferring any data 2019.04.08 00:54:05 LOG3[3]: please report the problem to Michal.Trojnara(a)stunnel.org 2019.04.08 00:54:05 LOG3[3]: stunnel 5.51 on x64-pc-mingw32-gnu platform 2019.04.08 00:54:05 LOG3[3]: Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 2019.04.08 00:54:05 LOG3[3]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI 2019.04.08 00:54:05 LOG7[3]: errno: (*_errno()) 2019.04.08 00:54:05 LOG3[3]: protocol=TLSv1.3, SSL_pending=0 2019.04.08 00:54:05 LOG3[3]: sock_open_rd=Y, sock_open_wr=Y 2019.04.08 00:54:05 LOG3[3]: SSL_RECEIVED_SHUTDOWN=n, SSL_SENT_SHUTDOWN=n 2019.04.08 00:54:05 LOG3[3]: sock_can_rd=n, sock_can_wr=n 2019.04.08 00:54:05 LOG3[3]: ssl_can_rd=n, ssl_can_wr=n 2019.04.08 00:54:05 LOG3[3]: read_wants_read=Y, read_wants_write=n 2019.04.08 00:54:05 LOG3[3]: write_wants_read=n, write_wants_write=n 2019.04.08 00:54:05 LOG3[3]: shutdown_wants_read=n, shutdown_wants_write=n 2019.04.08 00:54:05 LOG3[3]: socket input buffer: 0 byte(s), TLS input buffer: 0 byte(s) 2019.04.08 00:54:05 LOG5[3]: Connection reset: 1169 byte(s) sent to TLS, 19088 byte(s) sent to socket 2019.04.08 00:54:05 LOG7[3]: Remote descriptor (FD=592) closed 2019.04.08 00:54:05 LOG7[3]: Local descriptor (FD=908) closed 2019.04.08 00:54:05 LOG7[3]: Service [RTSP] finished (0 left) As you can see, at 00:54:05 there's a log entry that says "transfer() loop executes not transferring any data". Any ideas about why is this happening on v5.51, and how could I solve it? By the way, should I e-mail this issue to Michal Trojnara as the logs suggests, or should I use this mailing list exclusively? Thank you, Ricardo.-- Best regards

1 0

Stunnel 5.51 Pop3 Problem?
by Colin 07 Apr '19

07 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

1 0

Re: [stunnel-users] V5.51 no support for OpenSSL 1.0.2 ?
by Peter Pentchev 05 Apr '19

05 Apr '19

On Fri, Apr 05, 2019 at 01:39:04PM +0000, Duncan Morris wrote: > Hi, > > The latest version of options.c, in the V5.51 source, uses a new function, which appears to only be present in OpenSSL 1.1.0 onwards. > > key_buf=OPENSSL_hexstr2buf(key_str, &key_len); > > Is it intentional that support for OpenSSL 1.0.2 has been dropped? But there is also this segment of code... #else /* OpenSSL older than 1.1.0 */ #define X509_STORE_CTX_get0_chain(x) X509_STORE_CTX_get_chain(x) #define OPENSSL_hexstr2buf string_to_hex #endif /* OpenSSL 1.1.0 or newer */ So it should build with OpenSSL 1.0.2, too. Have you actually experienced problems building it? 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

Is there a Win32 installer that supports sslVersionMin = TLS1.2?
by kent loving 01 Apr '19

01 Apr '19

I need to run a client on Win XP that connects to a server using TLS 1.2 or higher. Jose Alf posted that he made a test build of 5.50 in a win32 installer but uses OpenSSL 1.0.2p. And it does not seem to be official. The changelog says version 5.49, which has a win32 installer, also uses OpenSSL 1.0.2p. I can't tell if it supports TLS1.2. The man page implies I need OpenSSL 1.1.1 to get the sslVersionMin option. And, OpenSSL says v1.0.2 support ends in 9 months. Any advice is appreciated. Thanks, Kent Loving

3 2

OpenVPN with stunnel
by Heikki Lavaste 25 Mar '19

25 Mar '19

Hi, To bypass the office firewall to access home server, I'm trying to run openvpn over port 443 with stunnel. I managed to get to this point: Log on client side 2019.03.22 22:15:13 LOG5[38]: Connection closed: 352 byte(s) sent to TLS, 2067 byte(s) sent to socket 2019.03.22 22:15:19 LOG5[39]: Service [openvpn] accepted connection from 127.0.0.1:51265 2019.03.22 22:15:19 LOG5[39]: s_connect: connected x.x.x.x:443 2019.03.22 22:15:19 LOG5[39]: Service [openvpn] connected remote server from x.x.x.x:51266 2019.03.22 22:15:19 LOG5[39]: Connection closed: 352 byte(s) sent to TLS, 2067 byte(s) sent to socket Log on server side: Mar 22 22:21:54 ssh-server-heikki stunnel[2797]: LOG5[2797:140127128753920]: connect_blocking: connected 127.0.0.1:8443 Mar 22 22:21:54 ssh-server-heikki stunnel[2797]: LOG5[2797:140127128753920]: Service [openvpn] connected remote server from 127.0.0.1:49366 Mar 22 22:21:54 ssh-server-heikki stunnel[2797]: LOG5[2797:140127128753920]: Connection closed: 2067 byte(s) sent to SSL, 352 byte(s) sent to socket Config: Client [openvpn] client = yes accept = localhost:1337 connect = x.x.x.xg:443 cert = C:\Users\heikki_lavaste\Documents\stunnel\stunnel.pem verifyChain = yes verify = 2 CAfile = C:\Users\heikki_lavaste\Documents\stunnel\ca-cert.pem checkHost = stunnel.heikki-lab.local sslVersion = TLSv1 Server chroot = /var/run/stunnel sslVersion = TLSv1 pid = /stunnel.pid setuid = nobody setgid = nobody socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 cert = /etc/stunnel/stunnel.pem [openvpn] accept = 443 connect = localhost:8443 cert = /etc/stunnel/stunnel.pem The issue is probably nothing to do with stunnel but if somebody can help me figure this out, that'd be appreciated. Kind Regards Heikki

2 1

ERR_SSL_VERSION_INTERFERENCE on Google Chrome v 73.0.3683.86 and stunnel v5.51b1
by Kolan Koala 25 Mar '19

25 Mar '19

I cannot get TLS 1.3 to work with Chrome. TLS 1.3 works fine in firefox quantum v 66.0.1 over the same hardware, so this is not caused by middleboxes. It is a fault with stunnel or Chrome. ERR_SSL_VERSION_INTERFERENCE error occurs in Chrome and will not connect. For now the solution is to turn off TLS v1.3 in stunnel configuration and force TLS v1.2, but this is not a long term solution. Does anyone have a solution to use TLS 1.3 with chrome and stunnel together? Kolan

1 0

No more Win32 stunnel?
by John Hall 21 Mar '19

21 Mar '19

I've only just discovered that stunnel is seemingly no longer being updated for Win32; at any rate there has been no version 5.50 released for Win32. It would have been nice if there had been an announcement to that effect, as until now I was only subscribed to the announcements mailing list and had thus been in blissful ignorance. (For some reason I never saw ANY announcement for 5.50 - in fact I still seem to be on 5.47.) Given that there are a number of ports to different OSs by various people, is there any chance that someone might supply a Win32 port for future versions? (Sadly I lack the knowledge to do that myself.) -- John Hall

3 4

Verify peer immediately
by Phillip Hellewell 21 Mar '19

21 Mar '19

Hi, I have verifyPeer = yes in my client stunnel.conf. Is there any way to make it verify the peer right away instead of waiting until a connection is made (to the accept port)? I run stunnel with foreground = yes and would like it to exit right away if the peer doesn't have the appropriate cert/key. Thanks, Phillip

1 0

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

Re: [stunnel-users] Problem with name resolving on Centos 7
by tom 13 Feb '19

13 Feb '19

Hello, > Are you sure 'foobar.remote.site' should resolve? > Does "ping foobar.remote.site" work? yes, the host is resolved on commandline and other services on this system can reach this host. > Do you have a /var/run/stunnel/etc/resolv.conf file? No at this time I dont have this file, but it doesnt change anything if I copy the original from /etc to this lokation. But this brings me to the point try to dissable chroot and in this case stunnel is working as expected. So far so good - there is something wrong in the chroot jail. I try to put it to /var/run/stunnel - no luck, but maybe there are other files missing as well? regards Tom

4 10

Problem with name resolving on Centos 7
by tom 12 Feb '19

12 Feb '19

Hello, I've installed stunnel-4.56-6.el7.x86_64 on my Centos 7. I can't establish a connection. Seems to be something wrong with the name resolution, because if I use the IP derect, the tunnel works. Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526436416]: Service [cs] accepted (FD=3) from 127.0.0.1:10866 Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Service [cs] started Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Waiting for a libwrap process Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Acquired libwrap process #0 Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Releasing libwrap process #0 Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Released libwrap process #0 Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Service [cs] permitted by libwrap from 127.0.0.1:10866 Feb 12 11:58:00 server stunnel[52445]: LOG5[52445:139984526432000]: Service [cs] accepted connection from 127.0.0.1:10866 Feb 12 11:58:00 server stunnel[52445]: LOG3[52445:139984526432000]: Error resolving 'foobar.remote.site': System error returned in errno (EAI_SYSTEM) Feb 12 11:58:00 server stunnel[52445]: LOG3[52445:139984526432000]: No host resolved Feb 12 11:58:00 server stunnel[52445]: LOG5[52445:139984526432000]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Local socket (FD=3) closed Feb 12 11:58:00 server stunnel[52445]: LOG7[52445:139984526432000]: Service [cs] finished (0 left) stunnel.conf: socket = r:TCP_NODELAY=1 socket = l:TCP_NODELAY=1 options = CIPHER_SERVER_PREFERENCE TIMEOUTclose = 0 sslVersion = TLSv1 options = NO_SSLv2 options = NO_SSLv3 client = yes options = DONT_INSERT_EMPTY_FRAGMENTS cert = /etc/stunnel/stunnel.pem key = /etc/stunnel/stunnel.pem debug = 7 chroot = /var/run/stunnel setuid = stunnel setgid = stunnel pid = /stunnel.pid fips = no [srvice] accept = 63123 connect = foobar.remote.site:63123 delay = yes Any suggestions are very welcome! Thanks in advance Tom

3 2

Stunnel 5.50 Transparent Both (Source+Destination)
by Luis Monteiro 01 Feb '19

01 Feb '19

Sirs. I´m trying to make Stunnel work in both source and destination transparent proxy and after looking every possibility I started to track the packet that is locally generated (Stunnel client sending to stunnel server). The packet goes out from process to raw table output chain. It deliveries to connect tracking that pass the packet to mangle output but it disappears before arriving in the nat table output chain. Stunnel Packet destination 7.0.0.2:80(Original destination)------raw/output-----connectTrack------mangle/output-------XXXX disappear With transparent destination off it works fine. Stunnel Packet destination 9.0.0.2:443(Stunnel Server IP)------raw/output-----connectTrack------mangle/output-------nat/output---- filter/output----interface The problem is probably regarding the tproxy/ip_transparent that stunnel use to control the connection and get the original src/dst to use. I tried 3 different distribution of linux with the same behavior. Does someone already use transparent=both and give me a setup that worked link linux distribution/version, stunnel version and so on? Thanks, Luis Monteiro

1 1

Re: [stunnel-users] How can stunnel use openssl HW cryptodev encryption
by Eric Eberhard 28 Jan '19

28 Jan '19

I'll give you two pieces of advice that almost everyone on the list won't agree with :) 1) Make a static openssl and static stunnel and locate them someplace apart from the standard locations (/usr/local/company_name/lib is what I use). This means if anyone messes with openssl or stunnel you won't be affected - and it will always work as it is static - and part of your application - the user does not even need your libraries. I have a personal distaste for dynamic linking . mostly because I have a lot of customers that update a lot of things (including openssl - a lot - and stunnel sometimes) . and then wonder why things stop working. A 10 year old openssl and stunnel - all static - will still run and work fine past all updates and user messing around. I choose when I want to update openssl and stunnel (meaning I look to see if there is something new I need or want). As a result I missed the keep alive and poodle bugs - I did not update until after both were fixed. 2) Forget hardware implementation - geez - modern computers are so darn fast that I cannot imagine you really need that level of "speed up" versus the grief you are handling. I have customers that exchange millions (4+) XML documents a day, all through stunnel, all through inetd (also not efficient supposedly - just reliable and always works and needs no management) - and have no problems. I am using IBM p Series (AIX) and these machines even at the low level are fast . but I also use some SCO and Linux and certainly with lesser volume they are fine as well. 3) OK - 3 is really - use inetd, so much easier and always works (assuming you have Unix). If inetd crashes Unix crashes so . see number 2 for reasons :) Of course, these ideas won't help much if you don't have a Unix variation or if you are really that tight on performance (although if you are I'd suggest hardware upgrades!). Good luck with your project, Eric From: stunnel-users [mailto:[email protected]] On Behalf Of Tamar Pedersen Sent: Wednesday, January 16, 2019 1:06 PM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] How can stunnel use openssl HW cryptodev encryption Hello, I am evaluating stunnel, to see if it is a viable solution for providing encryption in a system that contains an Atmel processor which includes a HW accelerated encryption block. I am just ramping up on stunnel, and figured I should capture what I have done so far. My questions will come towards the end of my email. My research indicates that stunnel incorporates openssl. I have been able to use openssl independently, to access the cryptodev HW encryption engine, in the Linux kernel module located in /lib/modules/4.14.79/extra/cryptodev.ko. When openssl is run without accessing the cryptodev engine (cryptodev module not loaded), I get the pure SW encryption implementation provided by default in openssl. When I run bench mark speed tests using openssl, using SW encryption, I see the following results: # time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 1689887 aes-128-cbc's in 2.95s Doing aes-128-cbc for 3s on 64 size blocks: 568389 aes-128-cbc's in 2.95s Doing aes-128-cbc for 3s on 256 size blocks: 151550 aes-128-cbc's in 2.96s Doing aes-128-cbc for 3s on 1024 size blocks: 38599 aes-128-cbc's in 2.96s Doing aes-128-cbc for 3s on 8192 size blocks: 4845 aes-128-cbc's in 2.95s OpenSSL 1.0.2p-fips 14 Aug 2018 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: arm-laird-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/home/sii/wb50n_space2_legacy_6.0.0.x/wb/buildroot/output/wb50n_space2_leg acy/host/arm-buildroot-linux-gnueabi/sysroot/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 9165.49k 12331.15k 13107.03k 13353.17k 13454.32k Command being timed: "openssl speed -evp aes-128-cbc" User time (seconds): 14.81 System time (seconds): 0.10 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 15.06s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 13376 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 145 Voluntary context switches: 0 Involuntary context switches: 721 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # When I load the cryptodev module, and take advantage of the accelerated hardware encryption the benchmark tests are significantly faster. Here is what those results look like. # modprobe cryptodev # time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 44163 aes-128-cbc's in 0.12s Doing aes-128-cbc for 3s on 64 size blocks: 31345 aes-128-cbc's in 0.15s Doing aes-128-cbc for 3s on 256 size blocks: 18923 aes-128-cbc's in 0.11s Doing aes-128-cbc for 3s on 1024 size blocks: 13847 aes-128-cbc's in 0.13s Doing aes-128-cbc for 3s on 8192 size blocks: 8427 aes-128-cbc's in 0.06s OpenSSL 1.0.2p-fips 14 Aug 2018 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: arm-laird-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/home/sii/wb50n_space2_legacy_6.0.0.x/wb/buildroot/output/wb50n_space2_leg acy/host/arm-buildroot-linux-gnueabi/sysroot/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 5888.40k 13373.87k 44038.98k 109071.75k 1150566.40k Command being timed: "openssl speed -evp aes-128-cbc" User time (seconds): 0.59 System time (seconds): 8.72 Percent of CPU this job got: 61% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 15.11s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 13792 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 144 Voluntary context switches: 41154 Involuntary context switches: 3321 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # As can be seen in the results (hi-lighted in red), the average speed to do aes-128-cbc encryption jumped from around 2.95 s to 0.10 s. Also of interest is the context switches are significantly higher when running hardware encryption, because of interrupts and overhead to use the hardware engine. I can also look at /proc/interrupts and see significant increases in atmel-aes interrupt counts when using the cryptodev HW acceleration encryption engine. This gives a good indication that the cryptodev module is in use, and is doing encryption. I would like to try to figure out how to allow stunnel to take advantage of the cryptodev HW acceleration encryption engine available in openssl. I have made some attempts, but so far, I have not been able to determine if stunnel is successfully using the cryptodev engine. Here is what I have done with stunnel. I already have a client and server successfully communicating with each other using stunnel. To verify this I used the "nc" utility to send characters back and forth between two different machines. The stunnel.conf file, on the server, is out of the box. I'm interested in encrypting on the client side. Here is my current client.conf file, in /etc/stunnel: # cat client.conf debug = 7 output = /tmp/stunnel-server.log pid = /tmp/stunnel.pid engine = cryptodev [test] verify = 1 client = yes accept = 127.0.0.1:2000 connect = 192.168.0.220:30000 CAfile = /etc/stunnel/certificate.crt engineNum = 1 # I am attempting to set up the cryptodev to be the configured engine for the client. I am able to start stunnel, using client.conf, as follows: # stunnel /etc/stunnel/client.conf # If I do a "ps" command to display processes, I can see that stunnel is running in the background. At this point, I can use "nc" to send data, as follows: # nc 127.0.0.1 2000 < /tmp/long_file.txt I am able to see the text from long_file.txt on the server, which is also running nc. The problem is that I don't see interrupts increasing in /proc/interrupts, which leaves me wondering if I have not configured stunnel correctly to use the cryptodev engine. If I try to remove the cryptodev module as this point, while stunnel is running, I receive a message that it is in use, as follows: # modprobe -r cryptodev modprobe: FATAL: Module cryptodev is in use. # If I kill the stunnel process, I am able to successfully remove the cryptodev module, which seems to suggest stunnel is the process using the cryptodev module. Also, once I have removed the cryptodev module, I can't restart stunnel. Instead, I get the following errors back: # stunnel /etc/stunnel/client.conf [.] stunnel 5.44 on arm-buildroot-linux-gnueabi platform [.] Compiled/running with OpenSSL 1.0.2p-fips 14 Aug 2018 [.] Threading:FORK Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI [ ] errno: (*__errno_location ()) [.] Reading configuration from file /etc/stunnel/client.conf [.] UTF-8 byte order mark not detected [ ] Enabling support for engine "cryptodev" [!] error queue: 2606A074: error:2606A074:engine routines:ENGINE_by_id:no such engine [!] error queue: 260B6084: error:260B6084:engine routines:DYNAMIC_LOAD:dso not found [!] error queue: 25070067: error:25070067:DSO support routines:DSO_load:could not load the shared library [!] ENGINE_by_id: 25066067: error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library [!] /etc/stunnel/client.conf:5: "engine = cryptodev": Failed to open the engine # Again, this suggests stunnel is trying to use cryptodev. I just don't know how to prove I am taking advantage of the HW encryption acceleration engine. I never see interrupts updating in /proc/interrupts when using nc, while stunnel is running. So, here are my questions: 1.) Does it look like I have things set up correctly in client.conf, to use the cryptodev engine? 2.) If client.conf is correct, how can I prove that stunnel is using the cryptodev engine, since I don't see the expected interrupts? One idea is that the cryptodev module might not support the type of encryption being requested by the certificate, so openssl falls back to the pure SW encryption implementation. I know the Atmel chip in question supports the following: # openssl engine -t -c (cryptodev) cryptodev engine [RSA, DSA, DH, DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, MD5, SHA1, SHA256, SHA384, SHA512] [ available ] (dynamic) Dynamic engine loading support [ unavailable ] # I was able to decode the contents of the certificate, and it says it is sha256WithRSAEncryption. My engine supports SHA256 and RSA, but does it support combining, like SHA256WithRSA? I'm not sure. I'll keep chasing that one. Thanks for any guidance on how to use the cryptodev in stunnel. Regards, Tamar

2 2

Max Performance of Stunnel
by Luis Monteiro 21 Jan '19

21 Jan '19

I'm testing Stunnel with Ixia traffic generator (Breakingpoint Virtual Edition) and I got a limited performance of 3.5Gbps full duplex even with 6 or 9 cpu in the esxi vm. The processors are fully dedicated as well memory all reserved with passthrough od network cards intel x540 10Gbps, 2 ports. The 2 vm are similar with one running stunnel client and the other as stunnel server. The page performance of Stunnel of 5.5Gbps but doesn't inform if it's half or full since in the operation the stunnel has to deal with 2 flow coming and going. If it was 5.5Gbps total makes sense since I'm using 2 x Scalable Gold 6140 and gave me 7Gbps encryption + decryption with AES-NI I think since we are not a feasible solution to check on the fly only the overall performance. I'm using the same cipher suit of performance information of Stunnel. Does anyone know if the performance numbers is considering the total performance or full duplex? Does someone have any tip to improve the performance? Thanks, Luis Monteiro

1 0