[Info-vax] DECserver/LAT across DECnet areas?

[Arne Vajhøj]

On 7/24/2023 7:33 PM, Johnny Billquist wrote:
> On 2023-07-25 01:02, Arne Vajhøj wrote:
>> On 7/24/2023 9:58 AM, Johnny Billquist wrote:
>>> On 2023-07-24 14:56, Simon Clubley wrote:
>>>> On 2023-07-23, Scott Dorsey <kludge at panix.com> wrote:
>>>>> Please don't remind me.  It's a horrible idea to contemplate, isn't 
>>>>> it?
>>>>
>>>>  From a security point of view, it (or something similar) is a really
>>>> good idea.
>>>
>>> Have you ever heard of "all eggs in one basket"? It's generally not a 
>>> good idea. When a security issue appears, *everything* is then 
>>> voulnerable. Having multiple solutions, implementations and 
>>> technologies carries a cost, but it also reduces risks in one way. 
>>> Yes, you might have a higher chance of having an exploit, but the 
>>> consequences are much less damaging. And you will always have 
>>> exploits. And thus, any argument about the number of exploits have to 
>>> acknowledge that first of all, there will be exlpoits. So, talking 
>>> about limiting the damages is the more reasonable/interesting thing 
>>> to do.
>>
>> I don't see HTTP as being particular relevant for security - so neither
>> good nor bad.
>>
>> We have stack like:
>>
>> application protocol
>> HTTP protocol
>> transport - either plain TCP or SSL
>>
>> The application protocol may or may not contain security
>> features and if it does then they may be good or bad.
>>
>> TCP has no security features. SSL has security features
>> that are constantly attacked which is why anything below
>> TLS 1.2 is no good today.
>>
>> But HTTP?
> 
> Did you miss the "S" at the end? As in "HTTPS".

HTTPS is not really a protocol. HTTPS is HTTP over SSL.

I don't see problem at the HTTP level.

At the SSL level maybe.

It is an observable fact that there has been numerous
vulnerabilities related to SSL usage. Which is why it
is constantly being updated.

But there are two types of problems with SSL usage.
Those that relate to SSL itself and those that
relates to the underlying algorithms.

If an alternative transport protocol XXX was invented
and HTTPX as HTTP over XXX was defined, then HTTPX would
be just as vulnerable to the algorithmic problems.

But a HTTPX would not change anything about web service
technology and its usage. URL's would start with httpx://
instead of https:// or http:// and they would need to
define a new default port instead of 443 and 80. But otherwise
business as usual.

Arne