Hi Neil, > On 6. Aug 2024, at 11:02, Neil Horman <nhor...@openssl.org> wrote: > > 1) Are distributions/users comfortable with this approach in the time frame > proposed?
I don’t think this will be a problem for Fedora, CentOS Stream, and RHEL. They mostly disable TLS <1.2 without a simple way to bring it back already. > 2) Would builders of OpenSSL consider using the default configuration (with > TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols > re-enabled in their builds? I would strongly argue for keeping those disabled in Fedora. It’s already not simple to re-enabled them in CentOS Stream or RHEL. > 3) If the deprecated protocols are re-enabled, what would constitute a > reasonable warning mechanism to inform users that these protocols are going > away at some point in the future to pressure users to update to a newer, > more secure protocol? I believe the best you can do as a library is what you are already doing: Disabling by default, and possibly marking any TLS-1.0/1.1-specific APIs deprecated. Logging to stderr from a library is out of the question. Logging to syslog can fail due to SELinux on distros that have it. The only other good solution we’ve come up with is to add a USDT probe point to deprecated code paths and provide a utility for users to run on their system that will highlight any use of these code paths. That’s Linux-specific, and most users won’t run such a tool, though. HTH, Clemens -- Clemens Lang RHEL Crypto Team Red Hat
