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

Fri Jun 7 20:24:46 CEST 2019

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: 899 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20190607/051f592b/attachment.sig>