[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66BD6C29.7060203@gmail.com>
Date: Wed, 14 Aug 2024 21:47:05 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: feedback requested regarding deprecation of TLS
1.0/1.1
Pat Gunn wrote:
> OpenSSL is an important and security-critical piece of software; it's
> important that it be maintainable, analysable for security properties, and
> that at runtime people don't have to worry about weird old code paths
> leading to breaches or instability.
>
By all means minimize the impact and refactor to reduce cruft, but do
not simply drop the old protocol support entirely. Doing so opens cans
of worms for some applications, while giving little actual benefit to
OpenSSL itself.
Further, OpenSSL is more than just a TLS library, it's actually a
cryptographic toolkit, so dropping TLS1.0/1.1 does not mean that any
ciphers can be removed, since the symmetric ciphers are also available
to applications directly. Presumably, they are used, albeit less commonly.
> Keeping these old code paths around (and particularly enabled) in "relative
> perpetuity" is bad for OpenSSL and bad for its users because it prioritises
> the long tail (that presumably see very little legitimate use nowadays)
> over the main use; there needs to be some kind of cut-off and acceptance
> that even if a few historical relics are cut off, it's better for the
> mainstream. There are other things that will make those legacies harder to
> use anyhow - cert chains, IPv6, potentially physical connectivity. Given
> the weights of the interests involved, it's not that hard to peel the relic
> cases from the it-works-automatically status into the
> you-may-need-to-take-extra-steps status.
>
There is a difference between "you may need to change configurations
and/or build these optional modules into your library" and "you'll
simply need an old version of the library for that". The other issues
you mention are either irrelevant for a LAN or easily worked around.
There are bizarre legacy systems out there. I have personally seen a
Token Ring hub with exactly one port active: its uplink to the router
that was bridging it to the Ethernet LAN.
> The Linux kernel removes support for old architectures for similar reasons.
>
> If someone were to argue a metric apart from relative perpituity, that'd be
> different, but I think any reasonable metrics of that flavour would have
> lines that have already been crossed in terms of usage numbers or any other
> measurable.
>
We did not have the same problem with SSLv3 because it was never as
widespread. TLS was far more successful and turned up in embedded
devices. The most serious problems with completely removing TLS1.0/1.1
come from general-reach applications that *do* need to be able to reach
those "last odd one out" devices, such as asset enumeration. Forcing
those applications to bundle an older (unmaintained) OpenSSL creates
risks that they will end up exposed to vulnerabilities in that old
OpenSSL version, which is bad because those applications are themselves
likely to be security-critical.
One way or another, we are likely stuck with a need for /some/ kind of
support for TLS1.0/1.1 for the foreseeable future. It need not be
enabled (or even compiled) by default, but it *does* need to be
maintained, on the mainline, not on some "premium support" side branch.
Vendors, even security vendors, will do stupid things to cut costs.
-- Jacob
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
