[stunnel-users] [Newsletter/Marketing] RE: stunnel-users Digest, Vol 181, Issue 3

Daniel Trickett daniel.trickett at milliporesigma.com
Fri Aug 23 00:38:03 CEST 2019


Hi

I did solve the issue with the solution as described in the first email in the chain. Thanks for your comments and support.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Eric Eberhard <flash at vicsmba.com>
Sent: Thursday, August 22, 2019 3:59:31 PM
To: 'Brent Kimberley' <brent_kimberley at rogers.com>; stunnel-users at stunnel.org <stunnel-users at stunnel.org>
Cc: Daniel Trickett <daniel.trickett at milliporesigma.com>
Subject: [Newsletter/Marketing] RE: [stunnel-users] stunnel-users Digest, Vol 181, Issue 3

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 at stunnel.org] On Behalf Of Brent Kimberley
Sent: Thursday, August 22, 2019 7:29 AM
To: stunnel-users at 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 at vicsmba.com<mailto:flash at vicsmba.com>>
To: "'Brent Kimberley'" <brent_kimberley at rogers.com<mailto:brent_kimberley at rogers.com>>,
    <stunnel-users at stunnel.org<mailto:stunnel-users at 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 at rogers.com<mailto:brent_kimberley at rogers.com>]
Sent: Tuesday, August 20, 2019 6:42 AM
To: stunnel-users at stunnel.org<mailto:stunnel-users at stunnel.org>
Cc: daniel.trickett at milliporesigma.com<mailto:daniel.trickett at milliporesigma.com>; flash at vicsmba.com<mailto:flash at 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://clicktime.symantec.com/3hPKYmesDrxGuE2bv5e7rh6H2?u=https%3A%2F%2Fwww.stunnel.org%2Fstatic%2Fstunnel.html%2520> ###############################################################################

[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 at milliporesigma.com<mailto:daniel.trickett at milliporesigma.com>>
To: "stunnel-users at stunnel.org<mailto:stunnel-users at stunnel.org>" <stunnel-users at stunnel.org<mailto:stunnel-users at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20190822/54949b97/attachment-0001.htm>


More information about the stunnel-users mailing list