Just dropping a couple of comments/questions here: 1) Does IETF also require use of TLS for communications inside one host (over localhost)? 2) Would a solution for two separate hosts be acceptable, where two TLS-Shims are started: * 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, * 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? 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. 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... Thanks for handling this and proposing practical solutions! Jim Klimov On Tue, May 25, 2021 at 12:29 AM Roger Price <roger at rogerprice.org> wrote:> When writing the Internet-Draft (I-D) "UPS Management Protocol" [1], I was > required by IETF rules to include a "Security Considerations" chapter. > This > meant saying clearly that the SSL provisions in NUT for secure > communication are > now outdated and deprecated. > > The IETF now insists on secure communication and this makes NUT's > situation an > issue for the project. > > In order to encourage discussion of this issue I would like to propose an > alternative to further work on upsd and the clients. I now have a working > demonstration at https://github.com/networkupstools/TLS-Shims [2] of the > TLS > solution described in the I-D, and based on this demonstration, I would > like to > propose: > > 1. That NUT separate TLS support from the upsd and client daemons. The > advantage is that updates to TLS will not require modification of upsd or > client > code. > > 2. That since generation of server and client certificates is now becoming > increasingly complicated, NUT provides a script which will produce a > self-signed > pair of certificates suitable for NUT server and clients. An example > of such a script is included in the NUT TLS-Shims repository. > > The demonstration scripts are written in a simple Python3. They are not > object > oriented. I recognize that use of Python introduces an additional > language > constraint into the project, but the large user base of Python means that > support will be available, and that interfaces such as Python/OpenSSL will > remain up-to-date. In early versions of NUT the C code was crafted not to > generate undue cpu load, but now, processors are more than able to process > the > same function in Python. > > The scripts are thoroughly documented in a new Part 2 to the Configuration > Examples version 2.0. In addition to Python's own error messages which > are > well done, the option -D provides detailed debugging output. > > The alternative to separating the TLS support is either abandoning > security, or > having to maintain it inside NUT, with more frequent releases needed to > keep up > with the rapid evolution of encryption. > > Roger > > [1] > https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-03.html > [2] Many thanks to Jim for the git wizardry which made this possible. > > _______________________________________________ > 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/20210525/e9aa65f8/attachment.htm>
On Tue, 25 May 2021, Jim Klimov wrote:> Just dropping a couple of comments/questions here: > > 1) Does IETF also require use of TLS for communications inside one host (over > localhost)?You have put your finger on a basic NUT exposure! First of all: The IETF's view of security is in RFC 3552 https://datatracker.ietf.org/doc/html/rfc3552 in which clause 5 covers "Writing Security Considerations Sections". In a Standards Track RFC authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. In our case, an attack on the lo interface is in-scope, and an attacker could eavesdrop the plain-text password. If this threat is deemed real in a given installation then we should say in the NUT documentation that the box running upsd should be single-user accessible by the sysadmin only. Our future RFC is not Standards Track and we are not held to the highest standard. But we should say something. Quoting RFC 3552 clause 5: ?While it is not a requirement that any given protocol or system be immune to all forms of attack, it is still necessary for authors to consider as many forms as possible.? I took the point of view that sniffing localhost traffic was unlikely since NUT server and client are not generally accessible. One would not use a machine serving employees/students for UPS management.> 2) Would a solution for two separate hosts be acceptable, where two TLS-Shims > are started: > * 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, > * 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?This is exactly the configuration I designed the shims for, and which I have tested. I did not consider pipe interfaces to upsd and client since that required modification of NUT code. The IETF consider two separate hosts across the Internet to be the base case. Quoting again from RFC 3552: The threat environment addressed by the Security Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place, even if only to provide justification for why such consideration is out of scope for the protocol. It is not acceptable to only discuss threats applicable to LANs...> 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. > > 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 insteadThe proposed script generates certificates with unlimited validity ?Dec 31 23:59:59 9999 GMT? as defined by RFC 5280 para 4.1.2.5. Roger
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 :) Jim On Fri, May 28, 2021 at 11:13 AM Roger Price <roger at rogerprice.org> wrote:> On Tue, 25 May 2021, Jim Klimov wrote: > > > Just dropping a couple of comments/questions here: > > > > 1) Does IETF also require use of TLS for communications inside one host > (over > > localhost)? > > You have put your finger on a basic NUT exposure! > > First of all: The IETF's view of security is in RFC 3552 > https://datatracker.ietf.org/doc/html/rfc3552 in which clause 5 covers > "Writing > Security Considerations Sections". In a Standards Track RFC authors MUST > describe > > 1. which attacks are out of scope (and why!) > 2. which attacks are in-scope > 2.1 and the protocol is susceptible to > 2.2 and the protocol protects against > > At least the following forms of attack MUST be considered: > eavesdropping, > replay, message insertion, deletion, modification, and > man-in-the-middle. > Potential denial of service attacks MUST be identified as well. > > In our case, an attack on the lo interface is in-scope, and an attacker > could > eavesdrop the plain-text password. If this threat is deemed real in a > given > installation then we should say in the NUT documentation that the box > running > upsd should be single-user accessible by the sysadmin only. > > Our future RFC is not Standards Track and we are not held to the highest > standard. But we should say something. Quoting RFC 3552 clause 5: ?While > it is > not a requirement that any given protocol or system be immune to all forms > of > attack, it is still necessary for authors to consider as many forms as > possible.? > > I took the point of view that sniffing localhost traffic was unlikely > since NUT > server and client are not generally accessible. One would not use a > machine > serving employees/students for UPS management. > > > 2) Would a solution for two separate hosts be acceptable, where two > TLS-Shims > > are started: > > * 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, > > * 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? > > This is exactly the configuration I designed the shims for, and which I > have > tested. I did not consider pipe interfaces to upsd and client since that > required modification of NUT code. > > The IETF consider two separate hosts across the Internet to be the base > case. > Quoting again from RFC 3552: > > The threat environment addressed by the Security Considerations > section MUST at a minimum include deployment across the global > Internet across multiple administrative boundaries without assuming > that firewalls are in place, even if only to provide justification > for why such consideration is out of scope for the protocol. It is > not acceptable to only discuss threats applicable to LANs... > > > 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. > > > > 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 > > The proposed script generates certificates with unlimited validity ?Dec 31 > 23:59:59 9999 GMT? as defined by RFC 5280 para 4.1.2.5. > > 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/20210612/7f515d1b/attachment.htm>