[stunnel-users] HELP! SSLv3 to TLSv1.2

[Peter Pentchev]

On Fri, Jun 07, 2019 at 02:50:11PM -0700, Eric Eberhard wrote:
> THANK YOU.  The two stunnel thing looks good and I will try it.  It is C
> code written by UPS in 2003!!!  And still working.  They claim it is SSLv3
> but I think it is too old for that.

I'm not sure why you would say this, since SSL 3.0 has been around since
1996 and the first signs of trouble with it appeared, if I remember
correctly, before the year 2000.

> I will have to play with it.  Since it
> is a once-a-day thing (to send in the manifest) I could use 20 stunnels on
> not care.  Your idea gives me hope.

Be advised that there is a scenario where this solution may not work:
if the client uses SSL/TLS correctly and checks the server certificate,
it may try to make sure that the latter is signed by a certificate
authority that the client has been configured to trust. If it turns out
that the CA is somehow hardcoded into the client's configuration, then
you will not be able to make it trust your stunnel (the one that
terminates the SSLv3 connection), since you cannot possibly generate
a server certificate signed by the certificate of UPS's CA. One might
even say that this - unfortunate for you - situation will actually be
SSL/TLS doing its job and preventing a man-in-the-middle attack, which
is essentially what you are trying to accomplish, albeit for a good
purpose.

Of course, if you can configure the client and give it a server
certificate or a CA's certificate that it should trust, you're good
to go.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

> -----Original Message-----
> From: stunnel-users [mailto:stunnel-users-bounces at stunnel.org] On Behalf Of
> Christopher Schultz
> Sent: Friday, June 07, 2019 11:25 AM
> To: stunnel-users at stunnel.org
> Subject: Re: [stunnel-users] HELP! SSLv3 to TLSv1.2
> 
> Eric,
> 
> On 6/7/19 13:53, Eric Eberhard wrote:
> > I have a weird problem.  A remote site that has always used SSLv3 
> > wants to use TLSv1.2 – normally that takes 5 seconds in the config file.
> > 
> > However, the remote site supplied the software that sends to them 
 
> > and does not supply a version we can use unless we upgrade O/S and 
> > JAVA and who knows what else for hundreds of customers.  In four days.
> 
> If this is Java, then the problem is likely with the JVM only and they might
> be able to get away with just upgrading the version of Java. They are
> probably using Java 6. If they move up to Java 8 (which is just about to be
> relegated to the digital dustbin!), then they get TLS 1.2 and, most likely,
> they won't see any compatibility issues.
> 
> Most outfits won't upgrade their Java version because they are scared.,
> ignorant, and/or don't have a good testing process. I've never had a problem
> upgrading Java. Not even to the later weirdo "modular" ones.
> 
> > Normally stunnel takes in clear text and sends it out in whatever you 
> > like (TLSv1.2 in this case).  And the reverse.
> > 
> > Can it take in SSLv3 and convert to TLSv1.2?
> 
> I do not believe you can do this with a single stunnel. stunnel connects
> cleartext to encrypted or vice-versa, depending on the value of the "client"
> setting.
> 
> But, the solution is simple: use two stunnels.
> 
> So, let's say that you need to "proxy" a connection incoming on port 443 out
> to another server on port 8443. The 443 traffic requires TLSv1.2 and the
> 8443 traffic can only handle SSLv3. Do something like this:
> 
> [incoming]
> protocol=TLSv1.2
> accept=localhost:443
> connect=localhost:444
> client=false
> 
> [outgoing]
> protocol=SSLv3
> accept=localhost:444
> connect=remote:8443
> client=true
> 
> 
> (The above are obviously not exact. You can't specify a protocol for a
> specific service, you can't specify both client=true and client=false in
> the same file, etc. Finally, you probably don't want to LIMIT the outgoing
> connection to SSLv3. You want it to handshake whatever it can get its hands
> on.)
> 
> > Of course conceptually
> > this is easy and just a logical extension of stunnel – in practice, if 
> > not there, it would be a job.  Which I might tackle – but I first 
> > wanted to get community input.
> 
> I think configuring two tunnels gets the job done without writing any new
> software.
> 
> -chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20190608/f4093f3d/attachment-0001.sig>