[TriLUG] supporting legacy SSL ciphers

[Alan Porter via TriLUG]

Hi guys,

Some of you were around in 2004-2006 when I worked at TMIO, "the oven place".  We worked on a very early "internet of things" kind of home oven that could be remotely controlled or pre-programmed to start cooking a meal in time for it to be done when you got home from work.

The oven was way ahead of its time -- remember, the first iPhone didn't come out until a year later.  It was also a pretty wacky project to work on.  Some of you might've attended the TriLUG talk on building the embedded Linux system that is at the heart of the oven.

Now in 2020, I am still supporting the 2006-era Debian server that those ovens connect to!  While the Java applet that you would use to remotely control the oven will no longer run in a browser, the one internet feature that still works on these things is the weather screen saver.

We made the fortuitous decision to proxy the weather through our server, rather than having the ovens connect directly to a weather service.  That enabled us to change the software on the server whenever various weather services (Yahoo weather, weather.com, NOAA) changed or discontinued their services.  This has happened several times.

I hear that NOAA is going to change their API once again, and so I would like to modernize the back end.  (1) Write the weather scripts in Python (2) jettison all of the proprietary remote-control server software (3) host it on a modern OS.

I have already written a python flask application that runs in a gunicorn WSGI server and will respond with the weather info that the ovens need.  And if I hit it with a browser with the same parameters the ovens send, I get the right stuff back.  It passes the "curl" test.

However, the ovens were made in 2006, and so they use 2006-era HTTPS.  And so my modern NGINX server can not even negotiate an HTTPS connection when the ovens try to connect.  To dig into this a little, I ran `ssldump -k my.key -i 'eth0' -dnq 'tcp and host SERVERIP and port 443' -SH` and it tells me what ciphers the oven is trying to use.  None of them are supported by NGINX and openssl on my modern server, even if I allow older SSL protocol versions.

ssldump starts with `C>S SSLv2 compatible client hello` and then `Version 3.1`.  So I am not sure if that means it's SSLv2 or SSLv3.  Some of the cipher names suggest it could do TLSv1.

At this point, some of you are going to tell me that these old ciphers and SSL protocols were deprecated for a reason, and I should upgrade the ovens.  NO CAN DO.  These machines are out in the wild, and they will try to connect and get weather as long as our domain resolves.  So I just want to serve the weather for a few more years, from a more modern server, if that's possible.

I wanted to see if I can get NGINX to use the old ciphers.  I downloaded the current version of openssl and recompiled it with `enable-weak-ssl-ciphers` and `enable-ssl3` configure flags.  But when I run `openssl ciphers`, I get the same list that I got with the stock version of openssl.

Do you think there is a way I can compile openssl with at least one of the acceptable ciphers?  And if I do, will NGINX use them to negotiate an HTTPS connection?

Alan




The ciphers from the client:

New TCP connection #2340: CLIENTIP(36335) <-> SERVERIP(443)
2340 1  0.0407 (0.0407)  C>S SSLv2 compatible client hello
   Version 3.1
   cipher suites
   TLS_RSA_WITH_RC4_128_MD5
   SSL2_RC4_128_WITH_MD5
   TLS_RSA_WITH_RC4_128_SHA
   TLS_RSA_WITH_AES_128_CBC_SHA
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
   TLS_RSA_WITH_3DES_EDE_CBC_SHA
   SSL2_DES_192_EDE3_CBC_WITH_MD5
   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
   TLS_RSA_WITH_DES_CBC_SHA
   SSL2_DES_64_CBC_WITH_MD5
   TLS_DHE_RSA_WITH_DES_CBC_SHA
   TLS_DHE_DSS_WITH_DES_CBC_SHA
   TLS_RSA_EXPORT_WITH_RC4_40_MD5
   SSL2_RC4_128_EXPORT40_WITH_MD5
   TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
   TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
   TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
2340 2  0.0410 (0.0002)  S>C  Alert
     level           fatal
     value           internal_error
2340    0.0411 (0.0001)  S>C  TCP RST