stunnel-users November 2019

stunnel-users@stunnel.org

15 participants
17 discussions

Re: [stunnel-users] Stunnel traffic fails to go via proxy set in
by Andrew Krause 11 Nov '19

11 Nov '19

Hi Jai, If your proxy supports the HTTP CONNECT method, you can try revising your settings to this: [KG_Self-Checkout] key = client.pem cert = client.pem client = yes accept = 127.0.0.1:5001 connect = wproxy.qut.edu.au:3128 protocolHost = ap01.alma.exlibrisgroup.com:6443 TIMEOUTclose = 0 TIMEOUTconnect = 200 TIMEOUTidle = 86400 sslVersion = TLSv1.2 protocol = connect Only the connect protocol supports using the protocolHost option. If this isn't supported by your proxy, you can try using Privoxy or Polipo between stunnel and your proxy. Socat is another option as well. Andrew Krause Schaumburg Township District Library -----Original Message----- At QUT Library we use Stunnel to encrypt SIP2 (ie. book borrowing) traffic from the self-checkout machines through to the Alma library services platform (as per https://developers.exlibrisgroup.com/alma/integrations/stunnel/ ) Our self-checkout machines run Windows 10 and are allowed limited internet access to two hosts (cloud.fetechgroup.com and ap01.alma.exlibrisgroup.com) via our institution's Squid proxy and I have our current WinHTTP proxy settings: Proxy Server(s) : wproxy.qut.edu.au:3128 Bypass List : *.qut.edu.au The proxy server settings are set for all protocols (HTTP, HTTPS, secure and FTP) and I've confirmed that web browser and the FE Technologies software is routing via wproxy.qut.edu.au. However Stunnel is still trying to connect to Alma directly. Our stunnel.conf is as follows (just FYI, the FE Tech software points to 127.0.0.1:5001 as our library services platform address): [KG_Self-Checkout] key = client.pem cert = client.pem client = yes accept = 127.0.0.1:5001 connect = ap01.alma.exlibrisgroup.com:6443 TIMEOUTclose = 0 TIMEOUTconnect = 200 TIMEOUTidle = 86400 sslVersion = TLSv1.2 Is there a way to force Stunnel to either respect the WinHTTP settings or configure it to route traffic to wproxy.qut.edu.au:3128 before initiating the connect = hostname:port? I did try protocolHost as follows, but I'm probably misunderstanding how it works https://www.stunnel.org/static/stunnel.html#SERVICE-LEVEL-OPTIONS [KG_Self-Checkout] key = client.pem cert = client.pem client = yes accept = 127.0.0.1:5001 connect = wproxy.qut.edu.au:3128 protocolHost = ap01.alma.exlibrisgroup.com:6443 TIMEOUTclose = 0 TIMEOUTconnect = 200 TIMEOUTidle = 86400 sslVersion = TLSv1.2 Any advice or assistance gratefully accepted, and apologies if this is a silly question - I'm just a librarian trying to make this thing work. Thanks, Jai Parker | Information Access Librarian QUT Library | Division of Administrative Services QUT | Kelvin Grove | D Block, Level 1 | Victoria Park Rd Kelvin Grove QLD 4059 P: 07 3138 3381 | E: lib.infoaccess at qut.edu.au<mailto:lib.infoaccess at qut.edu.au> | www.qut.edu.au<http://www.qut.edu.au/> ABN: 83 791 724 622 | CRICOS No. 00213J

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 184, Issue 4
by Brent Kimberley 08 Nov '19

08 Nov '19

From: Mark Brookes <mark(a)loadbalancer.org> To: Francois Robinette <frobinette(a)hotmail.com> >> OpenSSL 1.1.0k x Stunnel interaction... See tag 5.56b1Thanks. Can't find the 5.56b1 tag. Is it on a fork?https://github.com/mtrojnar/stunnel/network/members BTW. I had difficulty linking stunnel-5.56 (static) with OpenSSL 1.1.1d (static) as well. >> The stunnel guys have worked tirelessly to get this resolved. Its an >> interaction of openssl 1.1.0k and Stunnel. I think essentially openssl >> is doing something strange. They came up with a fix and its currently>> in the https://www.stunnel.org/downloads/beta/stunnel-5.56b1.tar.gz >> beta. You should give it a try and see if its resolves your issue. On Thu, 7 Nov 2019 at 19:36, Francois Robinette <frobinette(a)hotmail.com> wrote: > > I've seen other having the same issue without resolution so far... > But we do have the same issue: > > stunnel[7886]: segfault at 21 ip 00007f70aa1efcea sp 00007f6fa7797978 error 6 in libpthread-2.12.so[7f70aa1e5000+17000] >

1 0

Stunnel traffic fails to go via proxy set in winhttp (Windows 10)
by Library Information Access Team 06 Nov '19

06 Nov '19

At QUT Library we use Stunnel to encrypt SIP2 (ie. book borrowing) traffic from the self-checkout machines through to the Alma library services platform (as per https://developers.exlibrisgroup.com/alma/integrations/stunnel/ ) Our self-checkout machines run Windows 10 and are allowed limited internet access to two hosts (cloud.fetechgroup.com and ap01.alma.exlibrisgroup.com) via our institution's Squid proxy and I have our current WinHTTP proxy settings: Proxy Server(s) : wproxy.qut.edu.au:3128 Bypass List : *.qut.edu.au The proxy server settings are set for all protocols (HTTP, HTTPS, secure and FTP) and I've confirmed that web browser and the FE Technologies software is routing via wproxy.qut.edu.au. However Stunnel is still trying to connect to Alma directly. Our stunnel.conf is as follows (just FYI, the FE Tech software points to 127.0.0.1:5001 as our library services platform address): [KG_Self-Checkout] key = client.pem cert = client.pem client = yes accept = 127.0.0.1:5001 connect = ap01.alma.exlibrisgroup.com:6443 TIMEOUTclose = 0 TIMEOUTconnect = 200 TIMEOUTidle = 86400 sslVersion = TLSv1.2 Is there a way to force Stunnel to either respect the WinHTTP settings or configure it to route traffic to wproxy.qut.edu.au:3128 before initiating the connect = hostname:port? I did try protocolHost as follows, but I'm probably misunderstanding how it works https://www.stunnel.org/static/stunnel.html#SERVICE-LEVEL-OPTIONS [KG_Self-Checkout] key = client.pem cert = client.pem client = yes accept = 127.0.0.1:5001 connect = wproxy.qut.edu.au:3128 protocolHost = ap01.alma.exlibrisgroup.com:6443 TIMEOUTclose = 0 TIMEOUTconnect = 200 TIMEOUTidle = 86400 sslVersion = TLSv1.2 Any advice or assistance gratefully accepted, and apologies if this is a silly question - I'm just a librarian trying to make this thing work. Thanks, Jai Parker | Information Access Librarian QUT Library | Division of Administrative Services QUT | Kelvin Grove | D Block, Level 1 | Victoria Park Rd Kelvin Grove QLD 4059 P: 07 3138 3381 | E: lib.infoaccess(a)qut.edu.au<mailto:lib.infoaccess@qut.edu.au> | www.qut.edu.au<http://www.qut.edu.au/> ABN: 83 791 724 622 | CRICOS No. 00213J

1 0

Re: [stunnel-users] Extensions when negotiating TLS
by Christopher Schultz 05 Nov '19

05 Nov '19

Tom, On 11/4/19 17:59, Tom (AST) Watson wrote: > Trying to make the applications want to talk http/1.1 isn't going to > be easy. Both sides (app#1 and app#2) want to talk http2 (*SIGH*). Understood. > I was just hoping stunnel might work. Presently it looks like it > won't so I am looking at alternatives. Part of the object is to look > at the various transactions over the wire (many!) and they are lots. > I assume that is why http2 is used, and I have no influence over > that decision. From the looks of it, making app#2 unencrypted is the > best path. Boo! > It is written in GO, and has little comments to describe things (such > is life!). I think I'm a bit closer to a solution, but if stunnel > can be made to work (ALPN support) it would be nice. Looks like I'll > have to wait. Why isn't it an option to enable encryption directly on the service? It seems like using stunnel should be your last resort. -chris > -----Original Message----- > From: stunnel-users <stunnel-users-bounces(a)stunnel.org> On Behalf Of Christopher Schultz > > Tom, > > On 11/4/19 17:16, Tom (AST) Watson wrote: >> Yes, I understand about ALPN. Sorry I described in detail. >> Unfortunately application #2 wants encrypted http2 (it is a go >> program). Application #1 wants to talk in http2 (I can't change >> that!) and it doesn't encrypt "naturally" (and I want to see what is >> going on [Wireshark] as well) In looking further I might be able to >> get application #2 to go plaintext (I found a pointer). Yes, it seems >> that stunnel doesn't support ALPN, wishful thinking on my part >> >> Back to the salt mines. (*SIGH*) > > How difficult would it be to enable HTTP/1.1 on that application #1? > I've never seen an h2-only service before. h2 is more effective for web applications that make a lot of tiny requests (like small resources for pages, scripts, etc.). Most API-based services don't really get any benefit from using h2. > > -chris > >> -----Original Message----- From: stunnel-users >> <stunnel-users-bounces(a)stunnel.org> On Behalf Of Christopher Schultz >> Sent: Monday, November 4, 2019 13:59 To: stunnel-users(a)stunnel.org >> Subject: [External] Re: [stunnel-users] Extensions when negotiating >> TLS >> >> Tom, >> >> On 11/4/19 16:05, Tom (AST) Watson wrote: >>> Well, I thought it would be "easy", but maybe not. I have an >>> application (#1) that uses http2, and isn't encrypted. No problem >>> here. Now I have another application (#2) that insists on using >>> https to talk to application #1. So I gleefully setup stunnel to >>> connect the two. Well, application #2 starts talking to stunnel with >>> a "Client Hello" packet, and it includes an extension "Application >>> Layer Protocol Extension" of "h2". >> >> This is called ALPN, and is a requirement for h2s. >> >>> While not versed in the minutia, I take this that the client >>> (application #2) wants to talk "http2" to the server (application >>> #1). >> >> Yep, pretty much. >> >>> OK, that is what I want. The problem is that stunnel doesn't respond >>> with ANY "Application Layer Protocol Extension" indicating acceptance >>> of this request in its "server hello". This means that application >>> #2 fails in its negotiation. No joy! >>> >>> Now I know that application #1 will nicely talk http2, but how do I >>> get stunnel to communicate this to application #2 (as encrypted >>> http2). Am I missing something in my (pretty simple) configuration >>> file? >> >> I can't find any references to stunnel supporting ALPN. You may be >> (temporarily) out of luck, at least with stunnel. >> >> You mentioned that app #2 insists on encryption (great, usually). Is >> there a requirement that it use h2? Or can it be configured to use >> HTTP/1.1? >> >> -chris >> >

2 1

Re: [stunnel-users] Extensions when negotiating TLS
by Christopher Schultz 04 Nov '19

04 Nov '19

Tom, On 11/4/19 17:16, Tom (AST) Watson wrote: > Yes, I understand about ALPN. Sorry I described in detail. > Unfortunately application #2 wants encrypted http2 (it is a go > program). Application #1 wants to talk in http2 (I can't change > that!) and it doesn't encrypt "naturally" (and I want to see what is > going on [Wireshark] as well) In looking further I might be able to > get application #2 to go plaintext (I found a pointer). Yes, it seems > that stunnel doesn't support ALPN, wishful thinking on my part > > Back to the salt mines. (*SIGH*) How difficult would it be to enable HTTP/1.1 on that application #1? I've never seen an h2-only service before. h2 is more effective for web applications that make a lot of tiny requests (like small resources for pages, scripts, etc.). Most API-based services don't really get any benefit from using h2. -chris > -----Original Message----- From: stunnel-users > <stunnel-users-bounces(a)stunnel.org> On Behalf Of Christopher Schultz > Sent: Monday, November 4, 2019 13:59 To: stunnel-users(a)stunnel.org > Subject: [External] Re: [stunnel-users] Extensions when negotiating > TLS > > Tom, > > On 11/4/19 16:05, Tom (AST) Watson wrote: >> Well, I thought it would be "easy", but maybe not. I have an >> application (#1) that uses http2, and isn't encrypted. No problem >> here. Now I have another application (#2) that insists on using >> https to talk to application #1. So I gleefully setup stunnel to >> connect the two. Well, application #2 starts talking to stunnel >> with a "Client Hello" packet, and it includes an extension >> "Application Layer Protocol Extension" of "h2". > > This is called ALPN, and is a requirement for h2s. > >> While not versed in the minutia, I take this that the client >> (application #2) wants to talk "http2" to the server (application >> #1). > > Yep, pretty much. > >> OK, that is what I want. The problem is that stunnel doesn't >> respond with ANY "Application Layer Protocol Extension" indicating >> acceptance of this request in its "server hello". This means that >> application #2 fails in its negotiation. No joy! >> >> Now I know that application #1 will nicely talk http2, but how do I >> get stunnel to communicate this to application #2 (as encrypted >> http2). Am I missing something in my (pretty simple) configuration >> file? > > I can't find any references to stunnel supporting ALPN. You may be > (temporarily) out of luck, at least with stunnel. > > You mentioned that app #2 insists on encryption (great, usually). Is > there a requirement that it use h2? Or can it be configured to use > HTTP/1.1? > > -chris >

1 0

Extensions when negotiating TLS
by Tom (AST) Watson 04 Nov '19

04 Nov '19

Well, I thought it would be "easy", but maybe not. I have an application (#1) that uses http2, and isn't encrypted. No problem here. Now I have another application (#2) that insists on using https to talk to application #1. So I gleefully setup stunnel to connect the two. Well, application #2 starts talking to stunnel with a "Client Hello" packet, and it includes an extension "Application Layer Protocol Extension" of "h2". While not versed in the minutia, I take this that the client (application #2) wants to talk "http2" to the server (application #1). OK, that is what I want. The problem is that stunnel doesn't respond with ANY "Application Layer Protocol Extension" indicating acceptance of this request in its "server hello". This means that application #2 fails in its negotiation. No joy! Now I know that application #1 will nicely talk http2, but how do I get stunnel to communicate this to application #2 (as encrypted http2). Am I missing something in my (pretty simple) configuration file? Thanks. -- Tom Watson (I'm at work now) Thomas.3.watson(a)raytheon.com

2 1

Debian 9 static build
by Chris Maciejewski 01 Nov '19

01 Nov '19

Hello, I am trying to build stunnel 5.55 on Debian 9 x64 statistically against latest OpenSSL build from source. The system already has openssl and libssl ver. 1.1.1b installed via apt-get , but I want to build against OpenSSL 1.1.1d instead. What I do is: 1. Build and install OpenSSL: $ cd /usr/src/openssl-1.1.1d $ ./config -fPIC --prefix=/opt/openssl $ make depend && make && make install 2. Build and install Stunnel $ cd /usr/src/stunnel-5.55 $ ./configure --with-ssl=/opt/openssl --enable-static $ make && make install Both 1 and 2 completes OK with no errors, however when I run: $ /usr/local/bin/stunnel [.] Compiled with OpenSSL 1.1.1d 10 Sep 2019 [.] Running with OpenSSL 1.1.1b 26 Feb 2019 .... and indeed when I do: $ ldd /usr/local/bin/stunnel libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f1083b4f000) libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f1083668000) above shows dynamic .so libs are used, rather than static libs libssl.a and libcrypto.a Any suggestions as to what is wrong with my process above and how to make static build of Stunnel to use non-system OpenSSL very much appreciated. Kind regards, Chris

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 November 2019