- stunnel-users - stunnel.org

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