[EXTERNAL] Re: Flow collection and analysis

Wed Jan 26 15:52:29 UTC 2022

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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220126/283730c1/attachment.html>