[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240807174807.GA4206@openwall.com>
Date: Wed, 7 Aug 2024 19:48:07 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: feedback requested regarding deprecation of TLS 1.0/1.1
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
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.
