[Nut-upsdev] TLS support in NUT

[Manuel Wolfshant]

On June 13, 2021 9:02:46 PM GMT+03:00, Tim Dawson <tadawson at tpcsvc.com> wrote:
>Let's not overlook the simple fact that a lot of deployments are behind
>secure firewalls, on secure networks, and on servers and lans that no
>users have access to (physical ormotherwise), and thus have negligible
>security requirements beyond what the environment already provides.
>Yes, the more advanced stuff may have validity and use some places, but
>the ability to stand up nut without that added layer of complexity has
>a lot of value as well . . . 
Absolutely correct. 


>
>(I run one of those environments, and frankly, would likely instantly
>cease to upgrade of all this was rammed down my throat and not a
>choice. 

Same here


>The idiotic deliberate breakage of Java in that many older
>systems can no longer have a functional network console, even on a
>secure network, is the perfect example of what *NOT* to do!)
Incidentally I fight for 2 weeks trying to obtain again control over an IBM chassis which requires an old Java

> The end
>user should *ALWAYS* have the choice - never a mandate!
>
My thoughts exactly ! Thank you for phrasing it out loud, Tim.



>
>On June 13, 2021 11:06:35 AM CDT, Manuel Wolfshant
><wolfy at nobugconsulting.ro> wrote:
>>On 6/13/21 3:36 PM, Jim Klimov via Nut-upsdev wrote:
>>> Haven't got many ideas on this today, preoccupied with other 
>>> house-work, but can share a couple :)
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> 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 :)
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> 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 :)
>>
>>1. There are miriad of scripts written on top of openssl and certutil 
>>that allow implementing a CA and issuance of certificates, with
>easy-rsa 
>>probably leading the lot (and usage basically consists of running 
>>./build-ca followed by ./build-key ( for v2 ) and equivalent
>parameters 
>>passed to the only script that easy-rsa v3 consists of ). Even f-droid
>
>>provides one for android, if I am not mistaken. I really do not see
>the 
>>need for yet another set of scripts that reimplement the wheel, 
>>especially as the existing programs provide a full stack of tools 
>>implementing all the stages a certificate can have, from creating a CA
>
>>to revoking a certificate.
>>
>>2. nut can be very nicely wrapped behind stunnel if a point to point 
>>connection between master and slaves is needed. Other tools also
>exist, 
>>are reliable and well known, tested and vetted. Therefore, from my
>point 
>>of view, even if the python shim approach is smart and nice, I do not 
>>see it as being really needed. A link to stunnel and an example
>included 
>>in the docs would do just as well. With all due respect, the shim idea
>
>>looks to me like a "not invented here" approach. To be clear: I am not
>
>>opposed to it but I would certainly not use it when "yum install
>stunnel 
>>/ apt install stunnel" are available.
>>
>>3. Last but not least, for anyone with low to moderate knowledge, 
>>letsencrypt takes minutes to setup and use and has the advantage of
>not 
>>requiring anything but running their script every 3 months.
>>
>>
>>wolfy