[Info-vax] BridgeWorks

[Arne Vajhøj]

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