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
>>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 anIBM 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. 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. 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. But setup becomes more complicated... Jim On Sun, Jun 13, 2021 at 8:53 PM Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:> 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 > > > _______________________________________________ > 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/20210613/e7fc4d27/attachment-0002.htm>
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>