April 2019 - stunnel-users

stunnel FIPS mode 140-2/ Other Modes
by mehmet ozisik 19 Sep '25

19 Sep '25

Hi All, I would like to ask a question about stunnel fips mode. There are lots of question and answers on the internet related with this, but I could not find any answer related with mine. I am compiling with openssl (auto detecting fips) . Here is a part of confgiure output : checking for FIPS_mode_set... yes configure: FIPS mode detected So I am thinking that fips also is being included. Then I try to run stunnel on target platform (in stunnel.conf fips=yes) and it gives below error : Compiled/running with OpenSSL 0.9.8w-fips 23 Apr 2012 Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Reading configuration from file stunnel.conf FIPS_mode_set: 2D06906E: error:2D06906E:FIPS routines:FIPS_CHECK_INCORE_FINGERPRINT:fingerprint does not match there are lots of information about this errror on internet. Then when I configure stunnel.conf with fips=no, stunnel is running successfully. I know that fips=yes means that enables FIPS 140-2 mode and I guess my fips canister does not supoort fips 140-2 mode (I do not know which fips mode it has supported). Now my question is coming : When I set fips=no, stunnel also starts with other available fips modes which the canister included? Or it skips running fips mode completely? Plase inform me if anyone has any idea? Regards

2 1

Requests to cloud server that requires host header
by Lorne Kates 13 Nov '24

13 Nov '24

(related to Akamai message from before-- but I have better troubleshooting information). I'm tying to route traffic through stunnel to a "cloud" based-endpoint. That endpoint has a static server name-- test.authorize.net. (This is the dev sandbox for auth.net) But if you do an nslookup on test.authorize.net, you'll get back a different servername and IP, because it's so wonderfully "cloud". Stunnel apparently tries to connect to the nslookup value. The server rejects the request because it can't route it back to test.authorize.net. I've tried adding "delay = yes" and "sni = test.authorize.net", but neither work. To see this in action, a simple setup with any accept, then connect to test.authorize.net:443 in client = yes mode. This is what a valid response looks like (13 -- give me the darn merchant ID in a POST): https://test.authorize.net/gateway/transact.dll This is what you'll get if you try to use stunnel (400 invalid url) : https://23.195.204.150/gateway/transact.dll So how can I get stunnel to send the proper Request Header (host: test.authorize.net) make sure it's using http/1.1, etc?

4 3

Re: [stunnel-users] CPU 100%
by Eric Eberhard 06 Nov '24

06 Nov '24

Long ago I had a server with a bad network card. Every once in a while it would spew uncontrollable bytes onto the network. If you open a stunnel connection and it does that this could very well be the problem. If it cheap, try changing the network card. If not, you should be able to look in your firewall/router and it will tell you who is sending what bytes to whomever. See if that machine is indeed streaming the bytes in massive quantities. If not, I would suspect your stunnel is getting stuck in it's own loop. There are a million reasons this can happen (well a few less than a million) - such as maybe a bad library in the FreeBSD or a bad choice in the Makefile - such as doing threads or something in a way your O/S does not like (I use threads=fork or whatever it is, instead of actual threading). You might tinker with some of the options that make the stunnel build and try different ones. Especially if stunnel was compiled on a different version of the O/S - could be differences in bytes in things and who knows what. That is all I can suggest beyond setting the debug level to 7 (I think is highest) and then watching the log file. Eric From: stunnel-users [mailto:[email protected]] On Behalf Of Murrey, Brian J. Sent: Wednesday, October 17, 2018 10:57 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] CPU 100% We are running stunnel 5.49 on FreeBSD 11.2 and we're running into a problem once in a while. CPU pegs at 100% when we get an stunnel connection from one of our external devices. This affects 100% of all cores and we can't even log in to console. To mitigate this temporarily, we have a script running in the background to watch when stunnel begins to spike and restarts the daemon. It doesn't happen 100% of the time, and so far I have been unable to distinguish what makes the connection do this to the CPU. Have any of you run in to this issue? Sincerely, Brian Murrey System Engineer II, IT Infrastructure _____ NOTICE: This message may contain privileged and confidential information and/or protected health information intended solely for the use of the named recipient and may be privileged or otherwise protected by law. If you are not the intended recipient of this message, you should immediately notify the sender and delete this message. Do not disseminate, reproduce, or review this message or attachments if you are not the intended recipient. The sender or others may have legal rights restricting the dissemination of the information contained in this message and, as a result, remedies against you in the event of the improper dissemination of confidential information, trade secrets, personal information or privileged communications. This message is the work of the sender and does not necessarily reflect the position, views, or policies of TriMedx LLC or its affiliates. WARNING: The integrity and security of this message cannot be guaranteed and may contain or transmit a virus or other illicit code. Neither TriMedx LLC or its affiliates accept liability for any damage attributable to viruses or illicit code transmitted through this message or an attachment.

2 1

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

04 Mar '24

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

8 41

Stunnel 4 failing to connect to gmail
by Asif Iqbal 11 Dec '20

11 Dec '20

I am faling to connect to gmail. Not sure what that bind error means. iqbala@ghar:~$ sudo stunnel4 2008.12.15 13:53:17 LOG7[3839:3083650736]: Snagged 64 random bytes from /home/iqbala/.rnd 2008.12.15 13:53:17 LOG7[3839:3083650736]: Wrote 1024 new random bytes to /home/iqbala/.rnd 2008.12.15 13:53:17 LOG7[3839:3083650736]: RAND_status claims sufficient entropy for the PRNG 2008.12.15 13:53:17 LOG7[3839:3083650736]: PRNG seeded successfully 2008.12.15 13:53:17 LOG7[3839:3083650736]: Certificate: /etc/stunnel/stunnel.pem 2008.12.15 13:53:17 LOG7[3839:3083650736]: Certificate loaded 2008.12.15 13:53:17 LOG7[3839:3083650736]: Key file: /etc/stunnel/stunnel.pem 2008.12.15 13:53:17 LOG7[3839:3083650736]: Private key loaded 2008.12.15 13:53:17 LOG7[3839:3083650736]: SSL context initialized for service ssmtp 2008.12.15 13:53:17 LOG5[3839:3083650736]: stunnel 4.22 on i486-pc-linux-gnu with OpenSSL 0.9.8g 19 Oct 2007 2008.12.15 13:53:17 LOG5[3839:3083650736]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP 2008.12.15 13:53:17 LOG6[3839:3083650736]: file ulimit = 1024 (can be changed with 'ulimit -n') 2008.12.15 13:53:17 LOG6[3839:3083650736]: poll() used - no FD_SETSIZE limit for file descriptors 2008.12.15 13:53:17 LOG5[3839:3083650736]: 500 clients allowed 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 10 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 11 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: FD 12 in non-blocking mode 2008.12.15 13:53:17 LOG7[3839:3083650736]: SO_REUSEADDR option set on accept socket 2008.12.15 13:53:17 LOG3[3839:3083650736]: Error binding ssmtp to 74.125.93.111:587 2008.12.15 13:53:17 LOG3[3839:3083650736]: bind: Cannot assign requested address (99) Here is how my conf file looks like iqbala@ghar:~$ cat /etc/stunnel/stunnel.conf | egrep -v "^;|^$" cert = /etc/stunnel/stunnel.pem foreground = yes sslVersion = SSLv3 chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 pid = /stunnel4.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 output = /var/log/stunnel4/stunnel.log client = yes [ssmtp] accept = smtp.gmail.com:587 connect = 25 Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu

5 9

Stunnel & Gmail security
by BOXI31 TEST 16 Oct '20

16 Oct '20

Hi all, To make "Stunnel 5.31" work with Gmail, I have to go in security settings of Gmail and "allow less secure apps to access my account". Is it mandatory ? Is it possible to set Stunnel to access Gmail without lowering it security level ? How ? I checked in log file TLS v1.2 is used by Stunnel but Gmail still consider it as a "less secure app." ! Regards, Steve

2 1

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