Safer DH key exchange in SSL mode

[Ghostbird]

Hi all,

I'm trying to fix my otmonitor code to use a safer DH key exchange. Currently my browsers (Firefox and Chrome) refuse to connect to SSL servers that use a key of less than 1024-bits for ephemeral Diffie-Hellman key agreement ( ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY ).

Proposed Solutions:

• Use Elliptic Curve Diffie Hellman for ephemeral keys (ECDHE) instead of the weaker default Diffie Hellman (DHE). (preferred)
• Force DHE to use a key of at least 1024 bits.
• Disable all DHE cipher suites used in SSL/TLS.

The TLS package is in the tclkit, not part of the source, and there ought to be an option to change the behaviour of TLS by modifying the lines that open the socket in web.tcl. However I have not found how to force ECDHE or disable DHE in the tls::socket call.

Does anyone have any experience with this?

[hvxl]

You can specify which cipher suites to use via the -cipher option. Syntax is as per OpenSSL.

[emmeesse68]

I've been playing around with ciphers lately to try and make my OTMonitor usable in https mode with Chrome/Firefox.

After trying some random ciphers with no appreciable result, I ended up scanning my OTMonitor with sslscan to get a list of supported ciphers, from which I was planning to select some strong suites to try with.

To my surprise, I saw otmonitor crashing when sslscan was checking tls1 ciphers. This happened on my debian box, on my modded version of otmonitor, repackaged as I said here domoticaforum.eu/viewtopic.php?f=75& ... tls#p74339.

I thought I broke something in the code, but the same thing happened with the original code I just downloaded. Worse, an sslscan crashes even the precompiled Windows executable - but in a different point (scanning some cipher in ssl3 protocol). Versions 4.2.0 and 4.2.1 of otmonitor.exe for Windows are immune, it appears that only versions 4.2.2 and later are affected. I'm afraid I didn't keep my old Linux executables to test them.

Maybe Tomorrow I'll try to understand which cipher from sslscan crashes which version of otmonitor, but I'm wondering if there's something that could explain why old versions don't crash, while they do after 4.2.2 was released...

[hvxl]

Somewhere around that time I switched the Tcl TLS package I used from version 1.6 to 1.6.4. The new one has much more current encryption methods, but apparently also more bugs. The old one dated back to 2008 and could only handle ssl 2, 3, and tls 1.0. So that was really no good anymore.

If you're really this concerned about security, I suggest you install a web server and let that handle the https connection. Then use a reverse proxy to serve up the otmonitor web pages. Any commonly used web server will get much more attention on encryption than I will ever be able to provide for otmonitor.

[emmeesse68]

Somewhere around that time I switched the Tcl TLS package I used from version 1.6 to 1.6.4. The new one has much more current encryption methods, but apparently also more bugs. The old one dated back to 2008 and could only handle ssl 2, 3, and tls 1.0. So that was really no good anymore.

Oh I see... now I understand the check for a version =< 1.6.4 in the web.tcl...

If you're really this concerned about security, I suggest you install a web server and let that handle the https connection. Then use a reverse proxy to serve up the otmonitor web pages. Any commonly used web server will get much more attention on encryption than I will ever be able to provide for otmonitor.

Well, I'm usually concerned but since I didn't allow access from the Internet it wasn't the case yet... I was simply trying to make it work with chrome and Firefox, 'cause those browsers are still complaining about a weak ephemeral DH key...That sounded like a red flag and induced me not to open that port on my firewall.

Anyway, thanks Schelte for the suggestion, the idea of reversing OTMonitor webpages with some other web server seems feasible but it's a bit overkill for my purpose, since I can remotely connect to my linux box and see web pages from there, if needed, so I might try it out, just as an experiment... and shut it down just after, not to have the hassle of continuously patching a publicly accessible web server...

[Ghostbird]

Thanks for the suggestion. I think I'll set that up. At the moment the otmonitor runs tls1 tls1.1 tls1.2, but I get complaints about the weak ephemereal DH key, so I can't access it from my Firefox. This is not a big issue, since my dad is the one who wants to control it through a UI, he uses Safari on iOS, which isn't so strict.

However every now and then, the program will start hogging the CPU, and the HTTPS interface becomes unresponsive. If this is a problem with the TLS library that's included, I could solve it by using a better web-server as reverse HTTPS proxy.
My other option is a watchdog daemon that polls the web interface every minute and restarts it when it becomes unresponsive.

[Ghostbird]

This was a fantastic solution, many thanks Schelte.
What I did was:

• Installed Apache 2
• Used the Let’s Encrypt client to get a free, valid SSL/TLS certificate. (Had to run it in certonly mode for some reason though, took me some time to figure that out. I got a weird error when running in --apache mode)
• Configured Apache 2 virtual host to redirect HTTP traffic to HTTPS
• Configured Apache 2 virtual host to handle HTTPS traffic with the Let’s Encrypt certificates, TLS 1.2 only, strong ciphers, and SSL Stapling.
• Configured Apache 2 virtual host to reverse-proxy HTTPS connections to http://localhost:8080 where otmonitor is listening.
• Configured iptables to allow incoming TCP connections on port 80 and 443
• Configured iptables to allow incoming TCP connections on port 8080 ONLY from localhost:443 to localhost:8080
• Configured the modem to forward ports 80 and 443 to the local server.
• Tested the configuration, it worked.
• Submitted the domain to the SSL Labs test. Scored an A. Not bad for a simple home automation server.

I really hope this also fixes the seemingly random crashes of the otmonitor.