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 <[email protected]> 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 > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
