stunnel-users August 2019

stunnel-users@stunnel.org

4 participants
12 discussions

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:stunnel-users-bounces@stunnel.org] 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 17 Oct '20

17 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] stunnel-users Digest, Vol 181, Issue 3
by Eric Eberhard 28 Aug '19

28 Aug '19

No. If it ain’t broke, don’t fix it! Old saying but still relevant. The continual updates in all modern software may fix something – and another broken. IMO. I know I am a minority on this this group but an old tried and true setup has great value. Experience, reduces updates and adds to stability. We don’t change our code unless we must. We think it is more stable. Don’t listen to me if you are the type that must have every update ASAP Listen to me if you don’t need the latest and greatest and your app works properly. Study the new version and make a plan to move forward when the time is right. We often move forward to the previous stable release. Often months or even a year later. If the improvements are for things you don’t use, put them off. Look at exactly what the release notes say to help you decide if the update is worth it, you might find it improves only functionality you don’t use. It saves time and money and does not introduce new bugs. We use a very unpopular method – we use inetd. This releases you from all the server management code which is very very very hard to make work on all systems as they work so differently. We are on IBM with AIX (Unix). I doubt a lot of people are testing that configuration. Stunnel is very good at not requiring you to update one step at a time! You can skip safely. Enough blather. I am sure there are a lot of people that disagree with me. And they are likely correct in certain situations. We suggest you look at your situation and and see if you can skip releases … All opinion, not fact. I am old-school so keep that in mind! Good Luck, Eric From: Brent Kimberley [mailto:brent_kimberley@rogers.com] Sent: Wednesday, August 28, 2019 8:16 AM To: stunnel-users(a)stunnel.org; Eric Eberhard <flash(a)vicsmba.com> Cc: daniel.trickett(a)milliporesigma.com Subject: Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3 Have you tried RFC8410? On Thursday, August 22, 2019, 04:00:43 p.m. EDT, Eric Eberhard <flash(a)vicsmba.com <mailto:flash@vicsmba.com> > wrote: <snip>We use similar logic with one stunnel and have millions of transactions daily... [4+10+1 mil XML+web calls]. <snip>R

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3
by Eric Eberhard 28 Aug '19

28 Aug '19

Thanks :) -- I think Daniel can solve his problem. If for some reason he cannot make the app server output clear text he has to do it as you laid out. If he can, he can do one stunnel with TLSv1.2 by making the app output clear text. Both will work and should be secure. I’d do the latter is possible – way less overhead doing encryption. We use similar logic with one stunnel and have millions of transactions daily (XML not cXML but that does not matter – ours are often fairly large as in 100s of MB). Encrypting clear to SSLv3 then back to clear to TLSv1.2 is three encryptions along that path instead of one by making the app output clear text. The app will also shrink if that matters as it won’t need encryption code. E From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Brent Kimberley Sent: Thursday, August 22, 2019 7:29 AM To: stunnel-users(a)stunnel.org Subject: Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3 >>there is no reason to connect to localhost with any security Should server/interface consolidation trigger functional/technical rework prior to go live? As per the diagram: the app server node x TLS engine node interface is wrapped in SSL the internal localhost x localhost interface is in the clear the TLS engine node x punchout-vendor node is wrapped in TLSv1.2 >> SNI flag (RFC 3546) Good catch. ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Aug 2019 08:01:08 -0700 From: "Eric Eberhard" <flash(a)vicsmba.com <mailto:flash@vicsmba.com> > To: "'Brent Kimberley'" <brent_kimberley(a)rogers.com <mailto:brent_kimberley@rogers.com> >, <stunnel-users(a)stunnel.org <mailto:stunnel-users@stunnel.org> > Thank you -- what I had in mind but I am not that fancy with the setups as we use one. We go from our application in clear text to stunnel TLSv1.2 which is clearly easier. I did make this work for a short while a long time ago and did not save the files. Plus no may people's horror we use inetd. Of course we only transfer 4 million XML docs per day and handle 10 million Web calls and another million connections for credit cards, etc. I have been told that if I had serious volume inetd is slower -:) but I have not noticed enough of a slowdown to matter. And inetd (at least on an IBM AIX server) is dead reliable and easy. As a curiosity -- as I often see people coding unnecessarily -- there is no reason to connect to localhost with any security at all unless your app can only output SSLv3 which would imply a 3rd party vendor. The traffic never hits the network in any way -- not even the network card -- it goes directly to/from the TCP/IP stack which is why I mentioned just making the app send clear text to one stunnel that outputs TLSv1.2 ... if possible (may not be if it is something you don't have source to). Eric -----Original Message----- From: Brent Kimberley [mailto:brent_kimberley@rogers.com <mailto:brent_kimberley@rogers.com> ] Sent: Tuesday, August 20, 2019 6:42 AM To: stunnel-users(a)stunnel.org <mailto:stunnel-users@stunnel.org> Cc: daniel.trickett(a)milliporesigma.com <mailto:daniel.trickett@milliporesigma.com> ; flash(a)vicsmba.com <mailto:flash@vicsmba.com> Subject: Re: stunnel-users Digest, Vol 181, Issue 1 Your mileage may vary. ############################################################################### # From internal application to external host ############################################################################### # [Int_Init] -> [Int_Term] -> [Ext_Init] -> [Ext_Term] ############################################################################### # [internal_initiator] ---ssl---> [Internal terminator] # [Internal terminator] ---http---> [external Initiator] # [external Initiator] ---tls---> [external terminator] ############################################################################### # https://www.stunnel.org/static/stunnel.html <https://www.stunnel.org/static/stunnel.html%20> ############################################################################### [Internal_Terminator] options = SSLv3 client = no accept = host_ip:443 connect = localhost:54321 CAfile = int_init_wallet.pem cert = int_term_pub.pem key = int_term_priv.pem [External_Initiator] options = SINGLE_ECDH_USE options = SINGLE_DH_USE ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 verify = 3? client = yes options = TLSv1.2 accept = localhost:54321 connect = externalhostname:443 verifyChain = yes renegotiation = no CAfile = ext_term_wallet.pem cert = ext_init_pub.pem key = ext_init_priv.pem ---------------------------------------------------------------------- Date: Mon, 19 Aug 2019 18:21:18 +0000 From: Daniel Trickett <daniel.trickett(a)milliporesigma.com <mailto:daniel.trickett@milliporesigma.com> > To: "stunnel-users(a)stunnel.org <mailto:stunnel-users@stunnel.org> " <stunnel-users(a)stunnel.org <mailto:stunnel-users@stunnel.org> > Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

3 2

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3
by Brent Kimberley 22 Aug '19

22 Aug '19

>>there is no reason to connect to localhost with any security Should server/interface consolidation trigger functional/technical rework prior to go live? As per the diagram: the app server node x TLS engine node interface is wrapped in SSL the internal localhost x localhost interface is in the clear the TLS engine node x punchout-vendor node is wrapped in TLSv1.2 >> SNI flag (RFC 3546)Good catch. ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Aug 2019 08:01:08 -0700 From: "Eric Eberhard" <flash(a)vicsmba.com> To: "'Brent Kimberley'" <brent_kimberley(a)rogers.com>, <stunnel-users(a)stunnel.org> Thank you -- what I had in mind but I am not that fancy with the setups as we use one. We go from our application in clear text to stunnel TLSv1.2 which is clearly easier. I did make this work for a short while a long time ago and did not save the files. Plus no may people's horror we use inetd. Of course we only transfer 4 million XML docs per day and handle 10 million Web calls and another million connections for credit cards, etc. I have been told that if I had serious volume inetd is slower -:) but I have not noticed enough of a slowdown to matter. And inetd (at least on an IBM AIX server) is dead reliable and easy. As a curiosity -- as I often see people coding unnecessarily -- there is no reason to connect to localhost with any security at all unless your app can only output SSLv3 which would imply a 3rd party vendor. The traffic never hits the network in any way -- not even the network card -- it goes directly to/from the TCP/IP stack which is why I mentioned just making the app send clear text to one stunnel that outputs TLSv1.2 ... if possible (may not be if it is something you don't have source to). Eric -----Original Message----- From: Brent Kimberley [mailto:brent_kimberley@rogers.com] Sent: Tuesday, August 20, 2019 6:42 AM To: stunnel-users(a)stunnel.org Cc: daniel.trickett(a)milliporesigma.com; flash(a)vicsmba.com Subject: Re: stunnel-users Digest, Vol 181, Issue 1 Your mileage may vary. ############################################################################### # From internal application to external host ############################################################################### # [Int_Init] -> [Int_Term] -> [Ext_Init] -> [Ext_Term] ############################################################################### # [internal_initiator] ---ssl---> [Internal terminator] # [Internal terminator] ---http---> [external Initiator] # [external Initiator] ---tls---> [external terminator] ############################################################################### # https://www.stunnel.org/static/stunnel.html ############################################################################### [Internal_Terminator] options = SSLv3 client = no accept = host_ip:443 connect = localhost:54321 CAfile = int_init_wallet.pem cert = int_term_pub.pem key = int_term_priv.pem [External_Initiator] options = SINGLE_ECDH_USE options = SINGLE_DH_USE ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 verify = 3? client = yes options = TLSv1.2 accept = localhost:54321 connect = externalhostname:443 verifyChain = yes renegotiation = no CAfile = ext_term_wallet.pem cert = ext_init_pub.pem key = ext_init_priv.pem ---------------------------------------------------------------------- Date: Mon, 19 Aug 2019 18:21:18 +0000 From: Daniel Trickett <daniel.trickett(a)milliporesigma.com> To: "stunnel-users(a)stunnel.org" <stunnel-users(a)stunnel.org> Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 181, Issue 1
by Eric Eberhard 21 Aug '19

21 Aug '19

Thank you -- what I had in mind but I am not that fancy with the setups as we use one. We go from our application in clear text to stunnel TLSv1.2 which is clearly easier. I did make this work for a short while a long time ago and did not save the files. Plus no may people's horror we use inetd. Of course we only transfer 4 million XML docs per day and handle 10 million Web calls and another million connections for credit cards, etc. I have been told that if I had serious volume inetd is slower -:) but I have not noticed enough of a slowdown to matter. And inetd (at least on an IBM AIX server) is dead reliable and easy. As a curiosity -- as I often see people coding unnecessarily -- there is no reason to connect to localhost with any security at all unless your app can only output SSLv3 which would imply a 3rd party vendor. The traffic never hits the network in any way -- not even the network card -- it goes directly to/from the TCP/IP stack which is why I mentioned just making the app send clear text to one stunnel that outputs TLSv1.2 ... if possible (may not be if it is something you don't have source to). Eric -----Original Message----- From: Brent Kimberley [mailto:brent_kimberley@rogers.com] Sent: Tuesday, August 20, 2019 6:42 AM To: stunnel-users(a)stunnel.org Cc: daniel.trickett(a)milliporesigma.com; flash(a)vicsmba.com Subject: Re: stunnel-users Digest, Vol 181, Issue 1 Your mileage may vary. ############################################################################### # From internal application to external host ############################################################################### # [Int_Init] -> [Int_Term] -> [Ext_Init] -> [Ext_Term] ############################################################################### # [internal_initiator] ---ssl---> [Internal terminator] # [Internal terminator] ---http---> [external Initiator] # [external Initiator] ---tls---> [external terminator] ############################################################################### # https://www.stunnel.org/static/stunnel.html ############################################################################### [Internal_Terminator] options = SSLv3 client = no accept = host_ip:443 connect = localhost:54321 CAfile = int_init_wallet.pem cert = int_term_pub.pem key = int_term_priv.pem [External_Initiator] options = SINGLE_ECDH_USE options = SINGLE_DH_USE ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 verify = 3? client = yes options = TLSv1.2 accept = localhost:54321 connect = externalhostname:443 verifyChain = yes renegotiation = no CAfile = ext_term_wallet.pem cert = ext_init_pub.pem key = ext_init_priv.pem ---------------------------------------------------------------------- Date: Mon, 19 Aug 2019 18:21:18 +0000 From: Daniel Trickett <daniel.trickett(a)milliporesigma.com> To: "stunnel-users(a)stunnel.org" <stunnel-users(a)stunnel.org> Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

1 0

Re: [stunnel-users] https to https proxy
by Eric Eberhard 20 Aug '19

20 Aug '19

I'll bite - probably missing something. Why not have your application output clear text to stunnel and set stunnel to TLSv1.2? In other words, drop the SSL from your application. If that won't work I think you can do it with two stunnels (I got it to work once before I did the above). One accepts SSLv3 and outputs clear text . it is the client=no option. The output goes to a stunnel that is client=yes and is set to TLSv1.2 . which outputs to your final destination. The output from the client=no would be to localhost on some port that fires the second stunnel. I suspect you have to use different port numbers. All guesses as I am not sure exactly what you are doing . but if it helps, great :) Eric From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Daniel Trickett Sent: Monday, August 19, 2019 11:21 AM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] https to https proxy Hi, Our punchout vendor switched their site to only accept tls 1.2 over the weekend. Unfortunately our application will only support SSL. We are using stunnel with other vendors but can control the inbound host name. This recent one is one we can't manage as it is the software provider. I found a solution for doing https to https. I'm unclear how I get the first https traffic to route to stunnel as the initial call will be from the application will be to the external host.. Any thoughts on whether this would work for my situation? Appreciate any thoughts.. [Tunnel_in] client = yes accept = host_ip:443 connect = localhost:54321 [Tunnel_out] client = no accept = localhost:54321 connect = externalhostname:443 Best regards, Dan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users August 2019