<div dir="ltr"><div>Just dropping a couple of comments/questions here:</div><div><br></div><div>1) Does IETF also require use of TLS for communications inside one host (over localhost)?</div><div><br></div><div>2) Would a solution for two separate hosts be acceptable, where two TLS-Shims are started:</div><div>* one listens on the NUT server's network interface(s) and passes unencrypted packets to upsd on localhost (or via pipe) and replies back to the net,</div><div>* another runs on client connecting to the NUT server, and the unmodified NUT clients connect to it on localhost (or via pipe) with the plaintext NUT protocol?</div><div><br></div><div>This would be similar to use of stunnel (or maybe would just use stunnel if tested and deemed acceptable) to connect plaintext sides of the dialog using a secure channel.</div><div><br></div><div>3) In any case, having some solution for certificates is good, although people bothering about that (and a need to update the trust as these expire) might opt for a private CA and would trust its longer-lived cert instead - openssl, directly or wrapped in openvpn's EasyRSA scripts, makes that approach manageable too. Corporate users probably have a domain CA as well. Alternately, there is Let's Encrypt, at least for public domains...</div><div><br></div><div>Thanks for handling this 
and proposing 
practical solutions!</div><div>Jim Klimov<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 25, 2021 at 12:29 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">When writing the Internet-Draft (I-D) "UPS Management Protocol" [1], I was <br>
required by IETF rules to include a "Security Considerations" chapter.  This <br>
meant saying clearly that the SSL provisions in NUT for secure communication are <br>
now outdated and deprecated.<br>
<br>
The IETF now insists on secure communication and this makes NUT's situation an <br>
issue for the project.<br>
<br>
In order to encourage discussion of this issue I would like to propose an <br>
alternative to further work on upsd and the clients. I now have a working <br>
demonstration at <a href="https://github.com/networkupstools/TLS-Shims" rel="noreferrer" target="_blank">https://github.com/networkupstools/TLS-Shims</a> [2] of the TLS <br>
solution described in the I-D, and based on this demonstration, I would like to <br>
propose:<br>
<br>
1. That NUT separate TLS support from the upsd and client daemons.  The <br>
advantage is that updates to TLS will not require modification of upsd or client <br>
code.<br>
<br>
2. That since generation of server and client certificates is now becoming <br>
increasingly complicated, NUT provides a script which will produce a self-signed <br>
pair of certificates suitable for NUT server and clients.  An example<br>
of such a script is included in the NUT TLS-Shims repository.<br>
<br>
The demonstration scripts are written in a simple Python3.  They are not object <br>
oriented.  I recognize that use of Python introduces an additional language <br>
constraint into the project, but the large user base of Python means that <br>
support will be available, and that interfaces such as Python/OpenSSL will <br>
remain up-to-date. In early versions of NUT the C code was crafted not to <br>
generate undue cpu load, but now, processors are more than able to process the <br>
same function in Python.<br>
<br>
The scripts are thoroughly documented in a new Part 2 to the Configuration <br>
Examples version 2.0.  In addition to Python's own error messages which are <br>
well done, the option -D provides detailed debugging output.<br>
<br>
The alternative to separating the TLS support is either abandoning security, or <br>
having to maintain it inside NUT, with more frequent releases needed to keep up <br>
with the rapid evolution of encryption.<br>
<br>
Roger<br>
<br>
[1] <a href="https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-03.html" rel="noreferrer" target="_blank">https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-03.html</a><br>
[2] Many thanks to Jim for the git wizardry which made this possible.<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>