[Nut-upsdev] TLS support in NUT

Jim Klimov jimklimov at gmail.com
Sun Jun 13 13:36:54 BST 2021

Haven't got many ideas on this today, preoccupied with other house-work,
but can share a couple :)

Regarding two implementations - I believe NSS and OpenSSL are licensed
differently and/or are (initially were?) available non-overlapping on
different OSes. A quick googling now showed that they both were actually
provided under different licenses over different releases and years.

As long as NUT consumes "some way to secure the packets" and does not
really care what that way is, leaching onto one or another library was a
decent choice (and better than using just one and offering nothing on
platforms that do not support it).

I *think* the different ways of configuration apply to some features only
supported by (integration with?) one of those libraries, but can't vouch
for that OTOH :)

Regarding self-signed certs vs. private (corporate) CA vs. commercial -
technically they are all the same, politics and setup policies and
responsibilities differ. Back in my sys-admining days, we had a private CA
with in-house scripting for openssl for engineering gear (UPSes, PDUs,
IPMIs and equivalents) which gave some measure of security (encrypted
comms) for many devices with some ease of setup (one cert - engCA - to add
trust for in a browser or similar client).

Having an easy self-signed secure setup for small deployments (e.g. home
LAN) is certainly a welcome bonus - when several computers are protected by
one UPS and one upsd, but I'd expect (maybe biased) that any sort of small
office or larger deployment with more than a couple of NUT clients and/or
servers would go for a centralized cert setup. It is not too hard to
conjure up, with many free and commercial tools available to orchestrate
depending on the scale they would need.

As for listening on several interfaces and/or ports from a single upsd
instance, can't quickly check, so would fathom a guess that NUT codebase
did not have a reason to bother yet to support that. Otherwise, your points
(4) and (5) make sense and are "doable" generally, after some effort :)

Jim Klimov

On Sun, Jun 13, 2021 at 11:42 AM Roger Price <roger at rogerprice.org> wrote:

> 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
> 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
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210613/b821e4a3/attachment.htm>

More information about the Nut-upsdev mailing list