[Nut-upsdev] TLS support in NUT

[Roger Price]

On Sat, 12 Jun 2021, Jim Klimov wrote:

> On a related note, we have got a pull request 
> https://github.com/networkupstools/nut/pull/1043 submitted today, to add a way 
> of limiting the use of obsoleted ciphers in a NUT deployment. Reviews and 
> comments in the PR are welcome :)

I would like to comment more generally on TLS support in NUT.  The pull request 
is part of a project move to continue supporting up to date encryption of 
communications, but it also raises more general questions:

1) The NUT project supports two TLS implementations: OpenSSL and NSS.  The 
administrative setups in upsd.conf and upsmon.conf for the two differ.  In both 
cases it is accepted that the NUT system administrator will be using commercial 
certificates, with all the administrative complexity that commercial 
certificates imply.  Should this be the case?

2) For the experimental TLS shims upsdTLS.py and upsmonTLS.py, and for the 
experimental client UPSmon.py, I took the position that the NUT project should 
help the system administrator as much as possible in the certificate management. 
The required certificates are provided by script mkNUTcert.py which produces a 
pair of self-signed certificates specifically for use by NUT.  These provide 
better security, and are simpler to manage: the script knows where the files go. 
There is no hashing, no CSR or other complexity.  It seems to me that the NUT 
project could usefully move to "self-signed certificates preferred".

3) Does the NUT project need two implementations of TLS?

4) I hope that in the long term, if the proposed RFC is accepted, port nut/3493 
will remain "TLS on request using command STARTTLS", but port ups/401 will be 
"TLS required".

5) Is it possible to configure upsd.conf as follows:

  LISTEN <interface> 3493
  LISTEN <interface> 401

and listen on two ports?  I havn't tried it.

Roger