FWIW...
On Fri, May 8, 2015 at 2:16 AM, Michael Felt <mamf...@gmail.com> wrote:
> From my perspective - as a simple packager (re: openssl - old versions) I
> run into the problem of only being able to get to 0.9.8.k (AIX 5.3 TL12)
>
So, an operating system that has been unsupported for the past 2 years,
check...
> In short, there are ways around dependencies on old versions of openssl on
> AIX. And further, if a 'user' is not willing to upgrade their OpenSSL - why
> would you think they are going to upgrade to the latest httpd-2.2.x (or any
> version for that matter).
>
Indeed, most won't, hopefully they are busy deploying a supported OS still
receiving security updates, check...
The rules change - and we (read "me and other users") cannot reasonably
> claim "latest and greatest from ASF" while requiring support for insecure
> openssl.
>
And the latest and greatest is 2.4.{last}, not 2.2.{bump} legacy update,
and nobody would assume otherwise, check...
> IMHO - you, ASF, also have an implied responsibility to the users of
> Apache httpd powered sites. Being backward compatible too long keeps
> weaknesses alive.
>
Therefore we ensure everyone who would otherwise pick up security fixes in
the future will refuse to do so, because we stubbornly force a
breaking/incompatible behavior change on some subversion legacy
maintainence bump? And yourself, a packager, shipping new packages for an
operating system with vulnerabilities which are no longer being patched?
check...
I've proposed changing the *default* config, universally, across all
shipping versions. Yann proposes to enhance mod_ssl in non-breaking ways
even back to 2.2, because 75-80% of the deployed servers have yet to update
to 2.4. Not that most won't eventually, but right now, they are at 2.2.
About users who have deployed a server, you can rant about employing the
cudgel to the foolish administrators' skulls who won't re-configure their
systems, however that is not an effective tool to ensure users update to
the least-buggy, least-insecure subversion release of the software. It was
mentioned in another thread, but just as an example, ripping out SSLv3
essentially means that every user with older back-end services will *never*
update again, period. Is that a rational act by an upstream project?
When discussing 2.2 and 2.4, altering the behavior of an update is not in
scope. Upgrades are a multi-layered project which require other systems to
be rolled out first, in waves. In the case of back end applications, you
have a redevelopment cycle where you are adapting to the latest
Java/Python/PHP/whatever before the back end service can be updated to a
hosting framework which supports TLSv1.2 properly.
Altering the behavior of the next upgrade, 2.5.0-dev (trunk) is absolutely
in scope, and knowing it will be quite a while before that sees a General
Availability release, it makes the most sense to be forward-looking and
anticipate the state of TLS that much further down the road. That can
include ripping out SSLv3 and TLSv1.0.
