Add support for openssl-1.1.0 #504

arjendekorte · 2017-11-27T20:14:52Z

Tumbleweed (openSUSE) is switching to OpenSSL-1.1.0 shortly. Apply changes to server & client code and AutoConf magic to make this happen.

arjendekorte · 2017-12-01T11:38:53Z

I amended this pull request a couple of times, to add proper support for protocols > TLSv1.

The OpenSSL code was developed against openssl < 1.0.1. At that time, specifying TLSv1_client_method and TLSv1_server_method, was enough to disable the use of SSLv2 and SSLv3 and automatically the highest (being the only remaining one) was used. With TLSv1.3 just around the corned and in some industries, TLSv1 is nearing its end-of-life.

Rather than hardcoding the protocol to TLSv1, this pull requests let the client and server figure out the highest mutual understood version and use that. In order to facilitate debugging which one is actually used, I just added the reporting of the version in debug mode. I doubt it is worth reporting to the user.

clepple · 2017-12-07T14:03:44Z

Hi @arjendekorte, thanks for putting this together. I agree that the code should negotiate the newest TLS version, and it sounds like the newer OpenSSL APIs make this easier than the last time we looked at that.

If I am not mistaken, the negotiated TLS version should be visible in Wireshark (which would seem to me to be a good way to verify that no NUT traffic is in cleartext), so debug logging is probably sufficient.

At the risk of adding too much to the TODO list for 2.7.5, I think this is distinct enough from the other post-2.7.4 changes that we should be able to merge this without any trouble. I would like to do a bit of regression testing (probably this weekend) against packaged versions of NUT beforehand.

arjendekorte · 2017-12-07T14:26:32Z

Well, I guess we never looked at supporting newer TLS versions. The last time I looked at that piece of code (Nov 29, 2010) openSSL didn't support TLSv1.1 and TLSv1.2 (these were added in openSSL 1.0.1, released Mar 14, 2012). At that time supporting everything better than SSLv3, effectively meant TLSv1 only and since then, nobody bothered to add better handshakes when they became available.

For the record, I already tested interoperability pre- and post changes. With both server and client using the changed openSSL initialization code, TLSv1.2 is agreed (for both openSSL-1.0.2 and -1.1.0). If either one is 'old', TLSv1 is used. I did not check against NSS by the way. From looking at that code, it is not clear to me if it supports anything better than TLSv1, it seems to me it might suffer from the same in this aspect.

arjendekorte · 2017-12-07T14:36:50Z

As a side note, I'm working (low profile) on supporting the mbedTLS library as well. I'm loosely involved in OpenWRT/LEDE where this is the default SSL library. Due to constraints on size, both openSSL and NSS libraries are too bloated for a lot of hardware. This would make the mess the upsclient.c and netssl.c are already in even worse, so my proposal would be to remove the #ifdef hell we're in by splitting these in seprate modules:

net-nossl.c
net-openssl.c
net-nss.c
net-mbedtls.c

These would all expose the same functions and since there is very little common code between the different SSL libraries, picking the right one at link time makes more sense. From a maintenance point of view also preferred, since changes like the one above would only touch one SSL implementation, so the risk of accidentally breaking support for other SSL libraries will be lower.

dmacks · 2018-02-04T20:27:21Z

@clepple, I'm tracking openssl-1.1.0 status of fink packages; I'll tag nut as "pending". Let me know if you need help testing in the fink environment.

jimklimov · 2019-02-23T18:21:07Z

Just in case, was it tested against different versions of openssl, to at least compile with them all? :)

Now that we have travis testing, we can add test suites that would request different ubuntu versions (12, 14, now 16 recently) and/or point to specific openssl package versions to install in the testing buildenv.

arjendekorte · 2019-02-23T19:18:52Z

As written above, this was interoperability tested with both OpenSSL 1.0.2 and 1.1.0, the only supported versions nowadays. It should be fine with 1.0.1 though.

cotequeiroz

I'm making some suggestions, of which moving SSL_load_error_strings() is the most important, to avoid the use of a deprecated function (you could save a few bytes of real state in openwrt by not including them).

cotequeiroz · 2019-02-23T19:25:47Z

clients/upsclient.c

@@ -315,22 +310,35 @@ int upscli_init(int certverify, const char *certpath,
 	}

 #ifdef WITH_OPENSSL
+
+	SSL_load_error_strings();


This is done automatically, and was deprecated, starting with openssl 1.1.0; my suggestion would be to move it inside OPENSSL_VERSION_NUMBER < 0x10100000L

server/netssl.c

cotequeiroz · 2019-02-23T19:32:04Z

m4/nut_check_libopenssl.m4

@@ -57,8 +57,9 @@ if test -z "${nut_have_libopenssl_seen}"; then
 	AC_MSG_RESULT([${LIBS}])

 	dnl check if openssl is usable
-	AC_CHECK_HEADERS(openssl/ssl.h, [nut_have_openssl=yes], [nut_have_openssl=no], [AC_INCLUDES_DEFAULT])
-	AC_CHECK_FUNCS(SSL_library_init, [], [nut_have_openssl=no])


Checking for SSL_CTX_new would be enough for what we need.

cotequeiroz · 2019-02-23T19:33:23Z

clients/upsclient.c

-	ssl_method = TLSv1_client_method();
+	ssl_ctx = SSL_CTX_new(SSLv23_client_method());
+#else
+	OPENSSL_init_ssl(0, NULL);


This call is not necessary, as library initialization is done automatically now.

cotequeiroz · 2019-02-23T19:34:08Z

server/netssl.c

-	if ((ssl_method = TLSv1_server_method()) == NULL) {
+	ssl_ctx = SSL_CTX_new(SSLv23_server_method());
+#else
+	OPENSSL_init_ssl(0, NULL);


Not necessary, same as above.

* Add support for openssl-1.1.0 * Allow TLSv1 and higher (not just TLSv1) * Fix check for empty string * Report TLS handshake in debug mode * Update nut_check_libopenssl.m4 * Update upsclient.c * Update netssl.c

Add support for openssl-1.1.0

da1f5aa

clepple mentioned this pull request Nov 28, 2017

openssl 1.1 support #429

Closed

Arjen de Korte and others added 3 commits November 28, 2017 20:00

Allow TLSv1 and higher (not just TLSv1)

b15656e

Fix check for empty string

5a8308a

Report TLS handshake in debug mode

5ecfb0f

cotequeiroz mentioned this pull request Jun 1, 2018

Add compatibility with openssl 1.1.0 - minimal changes #558

Closed

Luo2Jie2 mentioned this pull request Jul 16, 2018

./configure --with-openssl fails with OpenSSL 1.1, SSL_library_init now a macro #571

Closed

cotequeiroz suggested changes Feb 23, 2019

View reviewed changes

arjendekorte added 3 commits February 24, 2019 18:31

Update nut_check_libopenssl.m4

ab0c8b4

Update upsclient.c

1dc34a5

Update netssl.c

108c31c

aquette merged commit 612c05e into networkupstools:master Mar 15, 2019

globin mentioned this pull request Sep 2, 2019

nut: fix build with openssl 1.1 NixOS/nixpkgs#67906

Closed

10 tasks

fxcoudert mentioned this pull request Nov 8, 2019

OpenSSL 1.0 removal Homebrew/homebrew-core#46454

Closed

17 tasks

opoplawski mentioned this pull request May 18, 2020

2.7.4 upsclient.c, netssl.c use deprecated TLSv1_client_method() #575

Closed

jimklimov mentioned this pull request Aug 9, 2022

Looking forward, verified OpenSSL 3.0 support is needed sometime soon #1547

Closed

4 tasks

jimklimov added enhancement SSL/NSS Issues and PRs about SSL, TLS and other crypto-related matters LEDE/*WRT embedded Linux firmwares OpenWrt/LEDE, DD-WRT, Tomato and such. Small-scale NUT. labels Sep 14, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for openssl-1.1.0 #504

Add support for openssl-1.1.0 #504

arjendekorte commented Nov 27, 2017

arjendekorte commented Dec 1, 2017

clepple commented Dec 7, 2017

arjendekorte commented Dec 7, 2017

arjendekorte commented Dec 7, 2017

dmacks commented Feb 4, 2018

jimklimov commented Feb 23, 2019

arjendekorte commented Feb 23, 2019

cotequeiroz left a comment

cotequeiroz Feb 23, 2019

cotequeiroz Feb 23, 2019

arjendekorte Feb 23, 2019

cotequeiroz Feb 23, 2019

arjendekorte Feb 23, 2019

cotequeiroz Feb 23, 2019

arjendekorte Feb 23, 2019

Add support for openssl-1.1.0 #504

Add support for openssl-1.1.0 #504

Conversation

arjendekorte commented Nov 27, 2017

arjendekorte commented Dec 1, 2017

clepple commented Dec 7, 2017

arjendekorte commented Dec 7, 2017

arjendekorte commented Dec 7, 2017

dmacks commented Feb 4, 2018

jimklimov commented Feb 23, 2019

arjendekorte commented Feb 23, 2019

cotequeiroz left a comment

Choose a reason for hiding this comment

cotequeiroz Feb 23, 2019

Choose a reason for hiding this comment

cotequeiroz Feb 23, 2019

Choose a reason for hiding this comment

arjendekorte Feb 23, 2019

Choose a reason for hiding this comment

cotequeiroz Feb 23, 2019

Choose a reason for hiding this comment

arjendekorte Feb 23, 2019

Choose a reason for hiding this comment

cotequeiroz Feb 23, 2019

Choose a reason for hiding this comment

arjendekorte Feb 23, 2019

Choose a reason for hiding this comment