[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJbOq15d8KaGn2NA-hdLAfSKSCNzhwfL3LAo5gAg-FEoS39L6w@mail.gmail.com>
Date: Tue, 6 Aug 2024 11:25:10 -0400
From: Neil Horman <nhorman@...nssl.org>
To: oss-security@...ts.openwall.com
Subject: Re: feedback requested regarding deprecation of TLS 1.0/1.1
I don't think outputting to stderr is feasible as OpenSSL might be used in
a use case that has no tty connected. Likewise there is no guarantee that
syslog will exist.
What would likely be reasonable would be a two fold approach:
1) Issue a warning on build if TLS1.1/1.0 were enabled at build time (or
some other build time notification)
2) augment openssl version (or other openssl applet) to indicate that
TLS1.1/1.0 support is built in but is deprecated
On Tue, Aug 6, 2024 at 11:17 AM Marco Moock <mm@...fdsl.de> wrote:
> Am Tue, 6 Aug 2024 05:02:14 -0400
> schrieb Neil Horman <nhorman@...nssl.org>:
>
> > 1) Are distributions/users comfortable with this approach in the time
> > frame proposed?
>
> As a user, this is acceptable for me, but I know there are still
> machines outside that only offer such old versions.
> Some of them can't be upgraded easily because the vendor doesn't
> provide any new versions.
>
> > 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?
>
> Is it reasonable to output that on STDERR any time those protocols are
> used?
>
> Maybe log to syslog?
>
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.
