Re: [EXTERNAL] Re: Flow collection and analysis

[Nick Suan via NANOG <nanog () nanog org>]

While I agree that, yes everything SHOULD support TLS, there's a perfectly good reason for terminating TLS in something 
like (nginx/caddy/apache/etc):  X number of things supporting TLS on their web interface means X number of ways of 
configuring TLS.   If I terminate it on nginx, there's only a single way: the nginx config, which is then farily easily 
leveraged into having a single set allowed protocols and  ciphers. 

On Wed, Jan 26, 2022, at 9:33 AM, Mel Beckman wrote:
> People who advocate TLS lash-ups like nginx front ends remind me of Mr. Beans DIY automobile security, which started 
> with a screwed-on metal hasp and padlock, and then continued to a range of additional “layers”. Not 
> “defense-in-depth”, merely unwarranted “complexity-in-depth”: 
>
> https://youtu.be/CCl_KxGLgOA
>
>
> TLS is a standardized, fully open-source package that can be integrated into even tiny IoT devices (witness this $10 
> WiFi module https://www.adafruit.com/product/4201). The argument that people who want intrinsically secure products 
> can just bolt-on their own security are missing the point entirely. Every web-enabled product should be required to 
> implement TLS and then let custiners decide when they want to enable it. Vendors who are so weak that they can’t 
> should have their products go straight into /dev/null. 
>
> -mel via cell
>
> > On Jan 26, 2022, at 6:51 AM, heasley <heas () shrubbery net> wrote:
> >
> > Wed, Jan 26, 2022 at 07:21:19AM -0600, Mike Hammett:
> >
> > > Why is it [TLS] even necessary for such a function? 
> >
> > confidentiality and integrity, even if you do not care about authentication.
> > I am surprised that question is asked.
> >
> > The fewer things that are left unprotected, the better for everyone.  those
> > with concern about erosion of their privacy and human rights benefit from
> > everything being protected, everywhere for everyone.