Sujet : Re: BridgeWorks
De : arne (at) *nospam* vajhoej.dk (Arne Vajhøj)
Groupes : comp.os.vmsDate : 24. Jul 2024, 14:56:11
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v7r15r$1ou0h$2@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla Thunderbird
On 7/24/2024 12:45 AM, Dave Froble wrote:
On 7/23/2024 8:16 PM, Arne Vajhøj wrote:
On 7/23/2024 3:16 PM, Dave Froble wrote:
On 7/22/2024 2:31 PM, Arne Vajhøj wrote:
Let us say that one has some code that use HTTPS. And
that programming language has a library that supports
TLS 1.3. Then in 5 years a vulnerability in TLS 1.3 is
found and TLS 1.4 is created. If a new version of the library
supporting TLS 1.4 becomes available then all fine - update the
library and the application is fine. But if not then the
application has a problem, because the available library is
not getting updated.
>
How does that differ from some "supported" implementation languages? Doesn't
matter if TLS 1.4 doesn't exist now, does it?
>
It is not like:
>
supported language => guarantee for updated library
not supported language => guarantee for no updated library
>
But the likelihood for an updated library is much higher
if the language is actively maintained, supported and
developed by the vendor, because there is an expectation that
there is a long term market for the library.
>
If the language has been EOL, not supported and superseded
by another product from the vendor, then the market has shrunk
and are expected to continue to shrink. That is a situation that
make many libraries drop support as well.
>
This is not just a theoretical thing.
>
If you look at third party COM components used by VB6 and VBS back
in the late 90's and early 00's, then most of it are gone. The move
may be pretty slow, but after 22 years then the market is heavily
reduced.
Well, if the issue is external communications, and it isn't always so, then there is always "Tunnel" (or whatever it is called).
In some cases an encrypted tunnel can be used to mitigate the
problem of unencrypted or weakly encrypted traffic.
But it is not always possible. Like in B2C scenarios.
And strictly speaking it does not provide the same
as app-to-app encryption.
The original claims were that one could not use old apps that were implemented in a currently unsupported language. That argument is full of holes. Trying to introduce communications into the discussion is just FUD.
The communication part is one possible part of what the old stuff would
be missing.
Arne