[TriLUG] supporting legacy SSL ciphers

[William Sutton via TriLUG]

I figured I would have seen a response by now.

Any reason you can't use Apache?

William Sutton

On Fri, 27 Nov 2020, Alan Porter via TriLUG wrote:

>
> 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
>
>
> -- 
> This message was sent to: William <william at trilug.org>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that 
> address.
> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web	: 
> https://www.trilug.org/mailman/options/trilug/william%40trilug.org
> Welcome to TriLUG: https://trilug.org/welcome