There are degrees of old; supporting people with a range of computers still likely to be out there with some numbers is different from catering to the very long tail (or museum pieces). Taking "the widest audience possible" too literally would require supporting HTTP forever, perhaps even host-less HTTP/0.9 (no vhosts). I think to even enter the tent of reasonability people need to accept that "widest possible" is not a sustainable metric, and that letting security-essential libraries evolve means letting them ditch dead weight that may be part of their penetration surface.
For expiring CA certs, I'm not aware of many tools that offer to bypass checks (although I also haven't verified that many do such checks); do you have examples in mind? I'm guessing for that ssl-obsolete idea, you'd want to use dlopen() or some equivalent so the symbols are never loaded at the same time, or just link with an older version of the library, making two different binaries with different linking if need be. I suspect these concerns are so niche that the few people who might be inconvenienced are also technologically sophisticated enough to find solutions. On Wed, 7 Aug 2024 at 13:50, Solar Designer <so...@openwall.com> wrote: > Hi, > > I think there are two categories of use cases that need a wide range of > supported protocol versions: > > 1. Hosting a public server that's meant to be usable by the widest > audience possible, including from both up-to-date and older systems. > For example, a website should display in latest web browsers, but > command-line downloads from the same server should also work from old > systems (e.g., running LTS distros). > > 2. Scanning or crawling a wide variety of systems, e.g. by a search > engine indexer, an asset enumeration tool, a security scanner, or during > a pentest. > > For both of these categories, it's desirable to have a maintained > library that supports this wide range of protocol versions. The proxy > solution that Demi Marie Obenour advocates for isn't of enough help. It > could kind of work for #1, but it'd require two different end-points > that users would need to explicitly choose between, or some other hacks. > For #2, a workaround is to use two libraries, maybe trying the newer one > first followed by a fallback to the older, but this may also be tricky > (e.g., linking them into the same program might clash). > > I have to admit that #1 is becoming difficult anyway as older CA certs > expire. OTOH, especially older tools allow to bypass the certificate > check easily (if they have it at all). > > On Wed, Aug 07, 2024 at 04:40:47PM +0200, niekt0 wrote: > > as a penetration tester, I would appreciate something like a package > > "ssl-obsolete", that would contain old, working code. While it is > probably not > > necessary to fix cryptography related bugs (we know that this part is > broken), > > it would be probably still nice to fix RCE bugs. > > Right. But if it's a separate package, then you also need a separate > tool chain using that package - e.g., programming language modules built > against it, then separate builds of the tools you use directly. Or just > an older LTS distro that's ideally still maintained enough to fix RCEs, > but then you may be unhappy everything else is also out of date. > > Now, I am not saying any of this is necessarily enough reason to keep > TLS 1.0/1.1 in OpenSSL 4.0. Possibly not. LTS distros to the rescue. > This would mean somewhat slower adoption of OpenSSL 4.0+, but quicker > deprecation of TLS 1.0/1.1 on the Internet. > > Alexander >
