stunnel-users May 2019

stunnel-users@stunnel.org

16 participants
30 discussions

Re: [stunnel-users] stunnel 5.54 on x64-pc-mingw32-gnu platform
by Brent Kimberley 24 May '19

24 May '19

>> Stunnel v5.54 (local) halts during tunnel setup with stunnel v4.56 (remote) FYI. stunnel-5.55b1-win64-installer.exe does not halt during tunnel setup. Thanks! <Snip><Snip>[ ] Running on Windows 6.2[ ] No limit detected for the number of clients[.] stunnel 5.55 on x64-pc-mingw32-gnu platform[.] Compiled/running with OpenSSL 1.1.1b 26 Feb 2019[.] Reading configuration from file ...[.] UTF-8 byte order mark detected..[ ] Initializing service [..][ ] Ciphers: ..[ ] TLSv1.3 ...[ ] TLS options: ..[ ] Loading certificate from file: [ ] Certificate loaded from file: [ ] Loading private key from file: [ ] Private key loaded from file: [ ] Private key check succeeded[.] Configuration successful[ ] Binding service [ ] Listening file descriptor created [ ] Setting accept socket options [ ] Service bound to 2019.05.23 20:26:54 LOG6[cron]: Executing cron jobs2019.05.23 20:26:54 LOG6[cron]: Cron jobs completed in 0 seconds2019.05.23 20:27:09 LOG5[0]: Service accepted connection from 2019.05.23 20:27:09 LOG6[0]: s_connect: connecting 2019.05.23 20:27:09 LOG6[0]: CERT: 2019.05.23 20:27:09 LOG6[0]: CERT: 2019.05.23 20:27:09 LOG5[0]: Certificate accepted at 2019.05.23 20:27:09 LOG6[0]: Session id: 2019.05.23 20:27:09 LOG6[0]: TLS connected: new session negotiated2019.05.23 20:27:09 LOG6[0]: TLSv1.2 ciphersuite: 2019.05.23 20:27:16 LOG6[0]: Read socket closed 2019.05.23 20:27:16 LOG6[0]: SSL_shutdown successfully sent close_notify alert2019.05.23 20:27:16 LOG3[0]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing2019.05.23 20:27:16 LOG5[0]: Connection closed: </Snip> On Friday, May 17, 2019, 9:18:41 a.m. EDT, Brent Kimberley <brent_kimberley(a)rogers.com> wrote: Hi.Stunnel v5.54 (local) halts during tunnel setup with stunnel v4.56 (remote) whereas stunnel v5.53 (local) successfully establishes tunnels with stunnel v4.56 (remote). Debug 7 (local) doesn't detect any issues. Does remote 4.56 need to be upgraded? Does local 5.54 need to be patched? Best Regards,BK v5.54 x v4.56[local]s_connect: s_poll_wait <someip>:443: waiting 10 secondshalt...[remote]2019.05.17 08:47:34 LOG5[13009:140578290554624]: Service [httpsx] accepted connection from 2019.05.17 08:52:35 LOG6[13009:140578290554624]: init_ssl: s_poll_wait: TIMEOUTbusy exceeded: sending reset 2019.05.17 08:52:35 LOG5[13009:140578290554624]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket v5.53 x v4.56[local] 2019.05.17 08:57:18 LOG7[0]: s_connect: s_poll_wait <someip>:443: waiting 10 seconds2019.05.17 08:57:18 LOG5[0]: s_connect: connected <someip>:443...[remote]2019.05.17 09:11:10 LOG5[13009:140578290333440]: Service [httpsx] accepted connection from 2019.05.17 09:11:10 LOG5[13009:140578290333440]: Certificate accepted: depth=....

1 0

Re: [stunnel-users] Connection never completes
by Joe Fitzgerald 22 May '19

22 May '19

I am observing the same behavior Mario is seeing with STunnel 5.54 on Windows Server 2012 R2 running as a client. In my case I am upgrading the client side from STunnel 5.01. The client and server connected without difficulty when both were at STunnel 5.01. >From the STunnel v 5.54 client log: 2019.05.22 16:58:19 LOG7[main]: Found 1 ready file descriptor(s) 2019.05.22 16:58:19 LOG7[main]: FD=332 ifds=r-x ofds=--- 2019.05.22 16:58:19 LOG7[main]: FD=352 ifds=r-x ofds=--- 2019.05.22 16:58:19 LOG7[main]: Service [EchoClient] accepted (FD=440) from 127.0.0.1:62387 2019.05.22 16:58:19 LOG7[main]: Creating a new thread 2019.05.22 16:58:19 LOG7[main]: New thread created 2019.05.22 16:58:19 LOG7[0]: Service [EchoClient] started 2019.05.22 16:58:19 LOG7[0]: Setting local socket options (FD=440) 2019.05.22 16:58:19 LOG7[0]: Option TCP_NODELAY set on local socket 2019.05.22 16:58:19 LOG5[0]: Service [EchoClient] accepted connection from 127.0.0.1:62387 2019.05.22 16:58:19 LOG6[0]: s_connect: connecting 192.168.128.162:40007 2019.05.22 16:58:19 LOG7[0]: s_connect: s_poll_wait 192.168.128.162:40007: waiting 10 seconds >From the STunnel v 5.01 server log: 2019.05.22 16:58:19 LOG7[5072]: Service [EchoServer] accepted (FD=572) from 192.168.128.104:62388 2019.05.22 16:58:19 LOG7[5072]: Creating a new thread 2019.05.22 16:58:19 LOG7[5072]: New thread created 2019.05.22 16:58:19 LOG7[3724]: Service [EchoServer] started 2019.05.22 16:58:19 LOG5[3724]: Service [EchoServer] accepted connection from 192.168.128.104:62388 2019.05.22 16:58:19 LOG7[3724]: SSL state (accept): before/accept initialization

1 1

Connection never completes
by Mario Ricciardi 22 May '19

22 May '19

I have Stunnel on two computers, both Win10 version 5.54. One works flawlessly on my home network, but the second will not complete the connection to POP3 Office365 on the work network. It gets to s_connect and freezes: 2019.05.21 22:50:19 LOG7[main]: Found 1 ready file descriptor(s) 2019.05.21 22:50:19 LOG7[main]: FD=220 ifds=r-x ofds=--- 2019.05.21 22:50:19 LOG7[main]: Service [POP3 Incoming] accepted (FD=780) from 127.0.0.1:51378 2019.05.21 22:50:19 LOG7[main]: Creating a new thread 2019.05.21 22:50:19 LOG7[main]: New thread created 2019.05.21 22:50:19 LOG7[2]: Service [POP3 Incoming] started 2019.05.21 22:50:19 LOG7[2]: Setting local socket options (FD=780) 2019.05.21 22:50:19 LOG7[2]: Option TCP_NODELAY set on local socket 2019.05.21 22:50:19 LOG5[2]: Service [POP3 Incoming] accepted connection from 127.0.0.1:51378 2019.05.21 22:50:19 LOG6[2]: failover: priority, starting at entry #0 2019.05.21 22:50:19 LOG6[2]: s_connect: connecting 52.96.24.210:995 2019.05.21 22:50:19 LOG7[2]: s_connect: s_poll_wait 52.96.24.210:995: waiting 10 seconds The sessions stay active, but this is as far as they get. I start stunnel GUI and attempt to connect to the active port and the above behavior is what I get. Using OpenSSL I can connect just fine, so there doesn't appear to be a firewall issue: +OK The Microsoft Exchange POP3 service is ready. [WQBRAFgAUABSADAAMQBDAEEAMAAwA DgANgAuAEMAQQBOAFAAUgBEADAAMQAuAFAAUgBPAEQALgBPAFUAVABMAE8ATwBLAC4AQwBPAE0A] user LoadAccept(a)example.com +OK pass LAxxxxxx +OK User successfully logged on. list +OK 4 356828 1 70284 2 70415 3 108104 4 108025 The stunnel config is super simple: ; Debugging stuff (may be useful for troubleshooting) debug = 7 output = stunnel.log ; ************************************************************************** ; * Service definitions (at least one service has to be defined) * ; ************************************************************************** ;Microsoft Outlook [POP3 Incoming] client = yes accept = 127.0.0.1:110 connect = outlook.office365.com:995 verifyChain = yes CAfile = ca-certs.pem checkHost = outlook.office365.com OCSPaia = yes I won't bother showing the log for the working machine, but it has the same config. I'm really hoping there is simply something missing from the Windows install. A coworker has the same problem on their fresh company provided Win10 install. My functioning Win10 pc is my personal machine. Thanks, Mario --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

hostapd & stunnel
by Johannes Eckhardt 20 May '19

20 May '19

Hi, I'm running stunnel 5.39 on a Raspberry Pi with Raspbian 9 (stretch). The Pi has two network interfaces (eth0, wlan0) and I'm running an access point with hostapd. What I want to do is to route all traffic from my wifi-clients (connected via wlan0) through stunnel/socks. working iptables configuration to access the internet from eth0/wlan0: iptables -A FORWARD -i eth0 -o wlan0 -m state --state \ RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; if add the following lines (from stunnel.org) local traffic on eth0 goes to the stunnel-server but my wireless clients can't access the internet anymore. I tried several configurations, but without success... # stunnel socks iptables -t nat -A OUTPUT -p tcp -d TARGET-SERVER --dport 9080 -j ACCEPT iptables -t nat -A OUTPUT -o lo -j ACCEPT iptables -t nat -A OUTPUT -p tcp --dport 9050 -j ACCEPT iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-ports 9051 iptables -t nat -A PREROUTING -p tcp --dport 9050 -j ACCEPT iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 9051 # /etc/stunnel/stunnel.conf [SOCKS Client Direct] client = yes PSKsecrets = secrets.txt accept = :::9050 connect = TARGET-SERVER:9080 [SOCKS Client Transparent IPv4] client = yes PSKsecrets = secrets.txt accept = 127.0.0.1:9051 connect = TARGET-SERVER:9080 protocol = socks Has anyone a solution for that? Best regards, Johannes

1 0

Version 5.54 'make check' fails test 042_inetd
by James Brown 20 May '19

20 May '19

Sorry, posted with incorrect subject. > On 20 May 2019, at 3:29 pm, James Brown <jlbrown(a)bordo.com.au <mailto:jlbrown@bordo.com.au>> wrote: > > Having problems installing version 5.54 on macOS X with this configure command: > > ./configure --with-ssl=/usr/local/Cellar/openssl(a)1.1/1.1.1b > > Configure runs OK, as does make. > > But ‘make check’ ends with: > > $ make check > Making check in src > make[1]: Nothing to be done for `check'. > Making check in doc > make[1]: Nothing to be done for `check'. > Making check in tools > make[1]: Nothing to be done for `check'. > Making check in tests > Making check in certs > /Library/Developer/CommandLineTools/usr/bin/make check-local > ./maketestcert.sh > keys & certificates successfully generated > ./maketestcert.sh finished > /Library/Developer/CommandLineTools/usr/bin/make check-local > ./make_test > Mon 20 May 2019 15:21:58 AEST > stunnel 5.54 on x86_64-apple-darwin18.5.0 platform > Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 > Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI > > test 010_require_cert ok > test 011_verify_peer ok > test 012_verify_chain ok > test 013_CRL_file ok > test 014_PSK_secrets ok > test 015_p12_cert ok > test 020_IPv6 skipped > test 021_FIPS skipped > test 022_bind ok > test 030_simple_execute ok > test 031_redirect ok > test 032_no_redirect ok > test 033_redirect_exec ok > test 034_no_redirect_exec ok > test 035_SNI ok > test 036_no_SNI ok > test 037_failover_prio1 ok > test 038_failover_prio2 ok > test 039_failover_rr ok > test 040_reload ok > test 041_exec_connect ok > test 042_inetd failed > error logs logs/042_inetd.log > test 043_session_delay ok > test 044_session_nodelay ok > test 045_include ok > test 046_resume_PSK ok > test 047_resume_redirect ok > test 048_resume_noredirect ok > test 050_ticket_secrets ok > test 110_failure_require_cert ok > test 111_failure_verify_peer ok > test 112_failure_verify_chain ok > test 113_failure_CRL_file ok > test 114_failure_PSK_secrets ok > test 115_failure_wrong_config ok > summary: success 32, skip 2, fail 1 > ./make_test finished > make[3]: *** [check-local] Error 1 > make[2]: *** [check-am] Error 2 > make[1]: *** [check-recursive] Error 1 > make: *** [check-recursive] Error 1 > > How can I fix this 042_ inetd failure? > > Also, why did it skip the IPv6 test? > > Thanks, > > James. > > _______________________________________________ > stunnel-users mailing list > stunnel-users(a)stunnel.org <mailto:stunnel-users@stunnel.org> > https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

2 2

5.54 fails - TLS directory not found
by James Brown 20 May '19

20 May '19

Having problems installing version 5.54 on macOS X with this configure command: ./configure --with-ssl=/usr/local/Cellar/openssl(a)1.1/1.1.1b Configure runs OK, as does make. But ‘make check’ ends with: $ make check Making check in src make[1]: Nothing to be done for `check'. Making check in doc make[1]: Nothing to be done for `check'. Making check in tools make[1]: Nothing to be done for `check'. Making check in tests Making check in certs /Library/Developer/CommandLineTools/usr/bin/make check-local ./maketestcert.sh keys & certificates successfully generated ./maketestcert.sh finished /Library/Developer/CommandLineTools/usr/bin/make check-local ./make_test Mon 20 May 2019 15:21:58 AEST stunnel 5.54 on x86_64-apple-darwin18.5.0 platform Compiled/running with OpenSSL 1.1.1b 26 Feb 2019 Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI test 010_require_cert ok test 011_verify_peer ok test 012_verify_chain ok test 013_CRL_file ok test 014_PSK_secrets ok test 015_p12_cert ok test 020_IPv6 skipped test 021_FIPS skipped test 022_bind ok test 030_simple_execute ok test 031_redirect ok test 032_no_redirect ok test 033_redirect_exec ok test 034_no_redirect_exec ok test 035_SNI ok test 036_no_SNI ok test 037_failover_prio1 ok test 038_failover_prio2 ok test 039_failover_rr ok test 040_reload ok test 041_exec_connect ok test 042_inetd failed error logs logs/042_inetd.log test 043_session_delay ok test 044_session_nodelay ok test 045_include ok test 046_resume_PSK ok test 047_resume_redirect ok test 048_resume_noredirect ok test 050_ticket_secrets ok test 110_failure_require_cert ok test 111_failure_verify_peer ok test 112_failure_verify_chain ok test 113_failure_CRL_file ok test 114_failure_PSK_secrets ok test 115_failure_wrong_config ok summary: success 32, skip 2, fail 1 ./make_test finished make[3]: *** [check-local] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 How can I fix this 042_ inetd failure? Also, why did it skip the IPv6 test? Thanks, James.

1 0

stunnel 5.54 on x64-pc-mingw32-gnu platform vs 5.53
by Brent Kimberley 17 May '19

17 May '19

Hi.Stunnel v5.54 (local) halts during tunnel setup with stunnel v4.56 (remote) whereas stunnel v5.53 (local) successfully establishes tunnels with stunnel v4.56 (remote). Debug 7 (local) doesn't detect any issues. Does remote 4.56 need to be upgraded? Does local 5.54 need to be patched? Best Regards,BK v5.54 x v4.56[local]s_connect: s_poll_wait <someip>:443: waiting 10 secondshalt...[remote]2019.05.17 08:47:34 LOG5[13009:140578290554624]: Service [httpsx] accepted connection from 2019.05.17 08:52:35 LOG6[13009:140578290554624]: init_ssl: s_poll_wait: TIMEOUTbusy exceeded: sending reset 2019.05.17 08:52:35 LOG5[13009:140578290554624]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket v5.53 x v4.56[local] 2019.05.17 08:57:18 LOG7[0]: s_connect: s_poll_wait <someip>:443: waiting 10 seconds2019.05.17 08:57:18 LOG5[0]: s_connect: connected <someip>:443...[remote]2019.05.17 09:11:10 LOG5[13009:140578290333440]: Service [httpsx] accepted connection from 2019.05.17 09:11:10 LOG5[13009:140578290333440]: Certificate accepted: depth=....

1 0

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:Jochen.Bern@binect.de] 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users May 2019