<div dir="ltr"><div>Haven't got many ideas on this today, preoccupied with other house-work, but can share a couple :)</div><div><br></div><div>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.<br></div><div><br></div><div>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).</div><div><br></div><div>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 :)<br></div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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 :)</div><div><br></div><div>Thanks,<br></div><div>Jim Klimov<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 13, 2021 at 11:42 AM Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 12 Jun 2021, Jim Klimov wrote:<br>
<br>
> On a related note, we have got a pull request <br>
> <a href="https://github.com/networkupstools/nut/pull/1043" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/1043</a> submitted today, to add a way <br>
> of limiting the use of obsoleted ciphers in a NUT deployment. Reviews and <br>
> comments in the PR are welcome :)<br>
<br>
I would like to comment more generally on TLS support in NUT. The pull request <br>
is part of a project move to continue supporting up to date encryption of <br>
communications, but it also raises more general questions:<br>
<br>
1) The NUT project supports two TLS implementations: OpenSSL and NSS. The <br>
administrative setups in upsd.conf and upsmon.conf for the two differ. In both <br>
cases it is accepted that the NUT system administrator will be using commercial <br>
certificates, with all the administrative complexity that commercial <br>
certificates imply. Should this be the case?<br>
<br>
2) For the experimental TLS shims upsdTLS.py and upsmonTLS.py, and for the <br>
experimental client UPSmon.py, I took the position that the NUT project should <br>
help the system administrator as much as possible in the certificate management. <br>
The required certificates are provided by script mkNUTcert.py which produces a <br>
pair of self-signed certificates specifically for use by NUT. These provide <br>
better security, and are simpler to manage: the script knows where the files go. <br>
There is no hashing, no CSR or other complexity. It seems to me that the NUT <br>
project could usefully move to "self-signed certificates preferred".<br>
<br>
3) Does the NUT project need two implementations of TLS?<br>
<br>
4) I hope that in the long term, if the proposed RFC is accepted, port nut/3493 <br>
will remain "TLS on request using command STARTTLS", but port ups/401 will be <br>
"TLS required".<br>
<br>
5) Is it possible to configure upsd.conf as follows:<br>
<br>
LISTEN <interface> 3493<br>
LISTEN <interface> 401<br>
<br>
and listen on two ports? I havn't tried it.<br>
<br>
Roger<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>