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
