[TriLUG] supporting legacy SSL ciphers

[Alan Porter via TriLUG]

About three months ago, I posed a question here about how to support "legacy" SSL/TLS ciphers on a modern web server.  The application was to continue supporting the weather screensaver on the 2006-era TMIO "internet ovens".

The problem in a nutshell: the ovens run a home-brewed Linux distro from 2006.  They connect via https to a server that I maintain, and that server fetches weather data from NOAA.  Modern servers will not accept SSL2 or SSL3 connections from a 2006-era browser.

This week, it got worse.  Now NOAA won't accept TLS 1.0/1.1 connections from our 2006-era web server.

We had some great solutions in the earlier thread.  Most of the discussion had to do with grabbing the source of the openssl or GnuTLS libraries and enabling ancient ciphers.

Aaron Joyner proposed writing a new weather feed app in 'go' using an older development environment, and then running it on the new server.  The static linking would ensure that it would still run OK on any host.  One problem is that I did not have 'go' installed on the old server, and good luck trying to 'apt-get install golang', since none of the Debian 4.0 "Etch" mirrors are still alive.

I started thinking about running the entire old server image in a virtual machine... a VM inside the virtual machine that Linode gives me.  But then I got to thinking smaller.  If not a full VM, how about a docker image.  And smaller.  If not a docker image, how about just a 'chroot'?

CHROOT is what I did... and it works!

I provisioned a brand-new server from Linode, and rsynced the entire filesystem from the 2006-era server into a subdirectory (we can call it $CHROOTDIR).  Then I removed all of the cruft, like years of old logs.

I used "stunnel" on the old image to listen to port 443 and forward it to an unencrypted port.  Like this:

exec chroot $CHROOTDIR /usr/bin/stunnel -d 0.0.0.0:443 -p $RUNDIR/weather.pem -A $RUNDIR/tmio-ca.pem -r 127.0.0.1:1443 -f -o /var/log/stunnel.log

This ancient stunnel runs in a chroot, so it uses all of the old 2006-era libraries to establish an SSL2 or SSL3 connection with any ovens that call in.  It forwards the connection to a local port (1443), where my modern python/flask app is running.  The flask app has one single endpoint, which checks the weather from NOAA (using modern TLS 1.3), and it returns the weather data back through the stunnel and down to the oven.

oven -- chroot/stunnel -- nginx/gunicorn/flask -- NOAA

* oven speaks SSL2 to chroot/stunnel on port 443
* chroot/stunnel speaks plain HTTP to nginx/gunicorn/flask
* flask speaks modern TLS to NOAA

Testing this was just a matter of trying each link enough to tell they were working.  The first step was to hit my server with Qualys's scanning tools at https://www.ssllabs.com/ssltest/analyze.html?d=my.server.fqdn&latest .  It greeted me with a big fat "F".  Excellent!

Then I tried some "curl" commands against the local unencrypted port 1443.  Eventually, I was able to connect all of the dots: nginx config, guniform config, shell script to run the stunnel command, systemd config to start the tunnel on boot.  The last step was to try the entire path from an oven (running in virtualbox on my laptop) up to NOAA and back.

Screenshot:
https://cloud.alanporter.com/index.php/s/eJpd5k8TqiAAgxc

Thanks for the lively discussion here about potential solutions to the problem of supporting ancient SSL clients.

Alan