Re: Port 80 deprecation

Sir,

W dniu 07.06.2021 o 22:55, Paul Vixie pisze:
> On Mon, Jun 07, 2021 at 04:11:08PM +0200, Rafal Pietrak wrote:
>> Hi Everyone,
>>
>> This is not my field (and I apologise to cut in), but...
>>
>> If not a list of "unnecessary" encryption, may be a list of "know
>> cases", where in "ordinary use", there is little to gain by encryption.
>>
>> ...since it is usually good know (explicitly) the state of the matter.
>>
>> -R
> 
> thank you for your wisdom. i fear that the decision of when to encrypt will

OK. I get it. ... and believe me, I was already ashamed, when I stroked
first chars of that response.

But pls let me explain myself before I fell silent. Just last words.

> already have been taken, perhaps at birth or in university, and that advice
> received later won't be heeded.

[------------]

> when new technologies like TLS lack support for earlier norms. i'm not
> going to make a private X.509 certificate, with or without a private CA,
> to authenticate "localhost". nor for hypervisor-private network addresses
> and their private names. and possibly not for campus-private or datacenter-
> private network addresses and their private names. but, that may be just me.

That may be more of us.

Still, we may be forced to.... in order to avoid explaining to our
bosses, why so many vulnerability alerts are there in our internal networks.

[-------------]

> for my part, the internet is too viral and we err grieviously by depending on
> access to "the core" while trying to reach our own local resources. i'm not
> going to encrypt traffic on my loopback network or similar local networks,
> even if this requirement leads me towards or away from a solution or provider
> for no other qualification reason than this one.
> 
> and that's why i agree with the previous author on this thread, who wrote:
> 
>> W dniu 07.06.2021 o??07:27, Willy Tarreau pisze:

[-----------]

> 
> i don't want that flame war either. at most we can enumerate implications,
> but stop well short of recommendations. reachability may connote trust of
> some kinds in some situations, but since this is explicitly incompatible
> with "zero trust", we would reach the limits of consensus very early on if
> we tried to document the trade-off's.
> 

Sorry to hear that, but OK. On the other hand I think that those flame
wars could be avoided.

then again:
1. a lot of people wouldn't encrypt local :80 traffic, for a lot of
reasons (a list here?), out of which one is the burdon of running
private/local SA.
2. still, some local traffic is "automagically" encrypted for us, like
encrypted SMB.

And this is the actual meaning of my ill advised initial response here:
if there are a lot of sensible reasons for leaving :80 as is (a list
would help), then may be there is a way to supplement HTTP (headers) for
some sort of "automagical" encryption? No "admin actions" (unlike CA),
just a configuration "yes/no" (similar to snakeoil certificate, but
"better/simpler")? I'd personally (as one of those who takes care of
localnets) would really appreciate it.

Now, I really don't want to bother you with things I should know, you
already know. So, I'm not following up here unless explicitly addressed.

Thank you and best regards.

-- 
Rafał Pietrak

Received on Tuesday, 8 June 2021 07:53:39 UTC