[Nut-upsdev] TLS support in NUT

[Manuel Wolfshant]

On 6/13/21 10:13 PM, Jim Klimov wrote:
> >>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
>
> My condolences. It usually went along the lines of "fire up a VM with 
> a 10-year old distro, (find and) install Java 5 or 6..."
> IIRC, some time around jdk-1.6.37 could be one of the pivot points for 
> that.

Yeah, I tried linux and windows ( CentOS 6 & W10 ) with all the 
combinations of firefox 52.8 ESR, 52.9 ESR, jre 1.6.32 , jre 1.6.45 and 
openjdk. Only linux+openjdk barely works but it is unusable because it 
sends a random number of keypresses each time I press any single key. 
Other combinations just trigger errors or display blank pages. The most 
frustrating thing is that I have a special VM with C6 which _worked_  
until a few months ago and I'll be damned if I know what did I do to 
break it. Because I am pretty sure _I_ broke it... somehow.


>
> Thanks for raising this point, a pain like this is indeed not 
> something we would want to force on all NUT users, maybe not even by 
> default, and it is worth keeping that in mind.
>
> On another hand, more and more laws (like, real-life legislation) and 
> by-laws (like, IETF asking "how do you secure your comms before we 
> take your protocol for publishing?") tend to require us as a community 
> to at least offer something in this regard.

As a guy doing security stuff for 20+ years and having several audits 
yearly, I feel you.


> And as mentioned earlier in the discussion, maybe it is best 
> "outsourced" from NUT codebase (or at least NUT makes it easy to 
> outsource, such as with stunnel or shims that Roger proposed), so that 
> "modern du jour" crypto protection of NUT protocol on the wire 
> (including loopback for those inclined) can evolve at a different pace 
> from NUT releases. If only crypto libs evolved as just drop-in 
> replacements, without API and ABI changes... Notably, things like 
> stunnel do just that - as far as NUT is concerned, there is a 
> black-box pipe to send some bytes to and get some back.

I still believe in the original linux concept of KISS and writing 
programs which can do as well as possible the fewest number of things 
possible and then daisy chain the tools as needed ( just as Roger 
implemented the shim but that ssh -L and stunnel already do ). Rather 
than making nut more complex in an area which is not its selling point, 
I find it better to develop the UPS drivers and delegate the encryption 
/ protection to the tools dedicated for this purpose.


> But setup becomes more complicated...
The moment you want security on top of almost anything, things become 
more complicated. Frankly nothing comes to mind that does not require at 
least ticking an additional button somewhere to switch between security 
models. Even if sometimes the clients hide the complexity ( like 
browsers which default to attempting to use https and things becoming 
funny when the servers reply with different content of http and https ), 
it is there. I am on IRC almost daily since 1994 and I still have to 
tick "this network uses SSL" when doing the initial configuration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210614/fbbfebc7/attachment-0001.htm>