- stunnel-users - stunnel.org

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

Re: [stunnel-users] stunnel-users Digest, Vol 183, Issue 4
by Brent Kimberley 26 Oct '19

26 Oct '19

Chris.Does this help? https://stackoverflow.com/questions/40454338/no-shared-cipher-at-ssl-accept… If you can rule out libraries like OpenSSL, then look at your config + initial setup exchange. Date: Fri, 25 Oct 2019 11:11:54 -0400 From: Christopher Schultz <chris(a)christopherschultz.net> Subject: Re: [stunnel-users] Strange connection failure in one environmentOn 10/25/19 10:09, Christopher Schultz wrote: > All, > > I've been using stunnel in two environments (dev, prod) for a long time > without any problems. Recently, my dev environment started acting funny > and I can't connect to it from outside the box. > > Can someone take a look and let me know if you have any suggestions for > where to look for a problem? > > Both environments have the following things in common: > > 1. Hosted in Amazon EC2, no load-balancer in the way > 2. Configuration requires client-certificate to connect > 3. All certificates are valid, self-signed, and properly-trusted by both > sides > 4. TLS configuration has been locked-down to TLSv1.2, selected cipher > suites, FIPS mode=off > 5. All versions are the same: stunnel 4.56 w/OpenSSL 1.0.2k-fips > > The production (working) environment happens to be i686 and the > development environment happens to be x86-86, but I don't believe that > is relevant. > > When I use e.g. "openssl s_client" to connect to the production > environment and I *do not* provide a client certificate, I am able to > perform the initial TLS handshake, get a cipher suite negotiated, etc. > and then the connection fails because I didn't provide the client > certificate, of course. I *can* see in the handshake the list of allowed > client certificates. > > When I do the same in development, I get a handshake failure. No allowed > client certificates are shown. No nothing. > > If I connect on localhost to the dev server, I get what I'm expecting: > allowed client certificates are listed, connection is closed because I'm > not using the client certificate. Connecting from another host gets my a > handshake failure. > > Again, there are no load-balancers or anything between the outside and > the EC2 instance. I'm connecting as directly as it's possible to > connect. The box definitely allows incoming connections on the port I'm > trying to use; the AWS security group is configured correctly. > > I have tried dropping ALL security configuration on the dev server's > stunnel.conf such as client-cert requirements, TLS protocols, cipher > suites, etc. and I get the same behavior every time. I'm starting to > think that it has nothing to do with my stunnel.conf configuration at > all, but I'm at a loss as to where to look, next. > > Any ideas? Some more information: 0. The error I get on the client is "handshake failure" and the stunnel server drops this log message: SSL_accept: 1408A0C1: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher Note that I have disabled all but TLSv1.2 on the server. Removing this restriction does not change the behavior. 1. I have multiple stunnel configuration files on this server. Actually, I have 4 of them. Connections to ports defined in 2 of these files are not connecting successfully. Connections to ports defined in the OTHER two files *are* connecting successfully. The configurations seem to follow a pattern: those using RSA certificates as the server-certificate are working as expected, while those with EC server-certificate are failing. When I say "working" versus "failing", I mean that this command will give me a cipher suite and master key, but still drop the connection because I'm not providing a client-certificate for these tests: $ openssl s_client -connect host:port 2. I have a Java-based service that *is* able to connect through this stunnel instance just fine. It's running on a recent version of Java 8. My CLI client (not OpenSSL) is also running the same version. My CLI client cannot connect. *weird* In both cases, I am using EC client certificates, but the certificates are different from each other. Both of these certificates are trusted by the server. 3. When using OpenSSL 1.0.2t, I *can* connect, get the list of acceptable client certificates, etc. even without providing a client certificate. When using OpenSSL 1.1.1d, I can *not* connect. So perhaps the inside/outside networking thing I was thinking the problem might be is incorrect. AFAIK, both versions of OpenSSL should be able to use EC certificates and cipher suites. Thanks, -chris

1 0

Strange connection failure in one environment
by Christopher Schultz 25 Oct '19

25 Oct '19

All, I've been using stunnel in two environments (dev, prod) for a long time without any problems. Recently, my dev environment started acting funny and I can't connect to it from outside the box. Can someone take a look and let me know if you have any suggestions for where to look for a problem? Both environments have the following things in common: 1. Hosted in Amazon EC2, no load-balancer in the way 2. Configuration requires client-certificate to connect 3. All certificates are valid, self-signed, and properly-trusted by both sides 4. TLS configuration has been locked-down to TLSv1.2, selected cipher suites, FIPS mode=off 5. All versions are the same: stunnel 4.56 w/OpenSSL 1.0.2k-fips The production (working) environment happens to be i686 and the development environment happens to be x86-86, but I don't believe that is relevant. When I use e.g. "openssl s_client" to connect to the production environment and I *do not* provide a client certificate, I am able to perform the initial TLS handshake, get a cipher suite negotiated, etc. and then the connection fails because I didn't provide the client certificate, of course. I *can* see in the handshake the list of allowed client certificates. When I do the same in development, I get a handshake failure. No allowed client certificates are shown. No nothing. If I connect on localhost to the dev server, I get what I'm expecting: allowed client certificates are listed, connection is closed because I'm not using the client certificate. Connecting from another host gets my a handshake failure. Again, there are no load-balancers or anything between the outside and the EC2 instance. I'm connecting as directly as it's possible to connect. The box definitely allows incoming connections on the port I'm trying to use; the AWS security group is configured correctly. I have tried dropping ALL security configuration on the dev server's stunnel.conf such as client-cert requirements, TLS protocols, cipher suites, etc. and I get the same behavior every time. I'm starting to think that it has nothing to do with my stunnel.conf configuration at all, but I'm at a loss as to where to look, next. Any ideas? -chris

1 1

ssl offloading with stunnel
by simona vittori 23 Oct '19

23 Oct '19

Hello,Is it possible to have the following architecture with stunnel? stunnel client --> balancer --> db server Balancer doesn't have stunnel product installed on it. It receives encrypted packages from stunnel client and redirect clear traffico to DB server. Is it possible to realize this configuration? Thank a lot. Regards Simona

1 0

stunnel : user identification in mutual auth
by Denis Polushin 22 Oct '19

22 Oct '19

Hi All, Haven't found the answer for this issue. The scheme is : TLS-client <==tls==> stunnel-server <==open==> App-server In user session stunnel-server perform authorization for client with its certificate (verify=2) and send request further to App-server. How does App-server can identify user in this session? To grand permissions. Ideally it would be good to know CN or EKU of user certificate. Is it possible? Thanks a lot!! Denis

1 0