[Nut-upsdev] TLS support in NUT
jimklimov at gmail.com
Sat Jun 12 15:29:47 BST 2021
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 :)
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
> > 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
> Security Considerations Sections". In a Standards Track RFC authors MUST
> 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:
> replay, message insertion, deletion, modification, and
> 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
> eavesdrop the plain-text password. If this threat is deemed real in a
> installation then we should say in the NUT documentation that the box
> 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
> attack, it is still necessary for authors to consider as many forms as
> 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
> serving employees/students for UPS management.
> > 2) Would a solution for two separate hosts be acceptable, where two
> > are started:
> > * one listens on the NUT server's network interface(s) and passes
> > 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
> 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
> 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
> > 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
> > bothering about that (and a need to update the trust as these expire)
> > 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 22.214.171.124.
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsdev