Re: Looking ahead to 2.4.13 / 2.2.30

[Michael Felt]

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).
With AIX 6.1 and 7.1 it would be openssl-1.0.0(something - do not know by
memory what patchlevel IBM openssl.base is at). Personally, I am going to
look at packaging against LibreSSL. There are only three #ifdefs I needed
to add to get it to build. My apologies for being so late with saying
anything about this (I have been busy with 'regular' work.

I will start a new thread later today - and do it again from trunks of
2.2.x, 2.4.x and 2.5.x.

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).

The rules change - and we (read me and other users) cannot reasonably
claim latest and greatest from ASF while requiring support for insecure
openssl. IMHO - you, ASF, also have an implied responsibility to the users
of Apache httpd powered sites. Being backward compatible too long keeps
weaknesses alive.

Michael

p.s. - for what is is worth +1 to drop 0.9.7 (maybe even 0.9.8 - but must
test more)

Michael

On Thu, May 7, 2015 at 11:50 PM, Yann Ylavic ylavic@gmail.com wrote:

 +1

 On Thu, May 7, 2015 at 6:45 PM, William A Rowe Jr wr...@rowe-clan.net
 wrote:
  Looking at the proposals in RFC 7525, I'm thinking this is a good time to
  re-sync
  httpd to these guidelines, even if it defers these releases by a week.
  WDYT?
 
  Bill
 
  On Fri, May 1, 2015 at 6:42 AM, Jim Jagielski j...@jagunet.com wrote:
 
  Yeah... I was gonna propose that once I had the weekend
  to take a more in-depth look at 2.4... But I am +1 for
  a release v. soon.
 
  Yeah, I'll RM 2.4
   On Apr 30, 2015, at 5:52 PM, William A Rowe Jr wr...@rowe-clan.net
   wrote:
  
   On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr.
   wr...@rowe-clan.net wrote:
   On Tue, 31 Mar 2015 10:49:47 -0400
   Jim Jagielski j...@jagunet.com wrote:
  
BTW: Would it make sense to consider a release of 2.4.13 in April
to coincide w/ ApacheCon?
  
   We've historically produced a release at the beginning of the con.
   It worked really well when we would hackathon two days, then retire
   to do other con stuff for the balance of the event with a new
   release in the hopper looking for votes.
  
   I'd love to see us tag and roll releases based on our efforts
   throughout the entire gathering, sometime in that following week.
   I offer to TR an update of 2.2 as well to pick up any issues we
   resolve over the course of that week.
  
   It seems that we have 2 groups of good things to come out of
 ApacheCon,
   some immediate fixes for things like BSD project efforts, some pretty
   straightforward defects that have been resolved... and then there's a
   bunch
   of energy about enhancements and the h2 universe.
  
   In the short term, WDYT about giving the trees a week to settle, grab
   the
   low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this
   coming
   week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR
 2.2.30
   in tandem.
  
   Concerns / observations / thoughts?
  
   Bill
 
 

Re: Looking ahead to 2.4.13 / 2.2.30

[Michael Felt]

I never assume it is easy. As far as AIX goes, it would be easier for me,
as a packager to ignore AIX 5.3. But, for now, what I package for AIX 5.3
(TL7 and later) also works on AIX 6.1 and AIX 7.1 - unchanged.

Getting people to update is hard. Some do it automatically - proud to be
bleading edge, some never update regardless of argument.

I would hope that by changing any requisites (e.g., minimal level of
openssl) would not change the behavior of the application. If it does, then
I would tend to follow (what I think you are saying) - that such a change
is not permitted. In that case, hurrying a new release where it is
applicable (e.g., 2.6.X) might be sensible - if a factor such as security
is the driving (emotional) motivator.

What was I thinking? Well, little me was considering the recent media
storms re: web-related security (when they mean the servers that browsers
connect to) - and what an organization (perhaps community is a better word)
could do to assist from the server side - rather than placing ALL the
responsibility and load on the remote device (phone, tablet, desktop).

So, yes - it it breaks the server by raising the bar as far as XXX is
concerned, we cannot, or maybe should not, raise that bar for those
releases with an improved XXX.

As far as OpenSSL goes - maybe the only affected component is mod_ssl. I am
probably completely offbase (I like simple worldviews when I can get away
with it) - but I thought OpenSSL is an API. I would hope the API for 0.9.7
and 0.9.8 are compatible; while openssl-1.0.0 and OpenSSL-0.9.X are not.
And again, that is only an issue if something in the new API is definitely
needed. If not, something like mod_ssl might still link against
OpenSSL-0.9.8 - but, as far as ASF httpd and mod_ssl is concerned -
security concerns with the root cause in openssl-0.9.8 are not supported.

Please excuse my rambling: too many phone calls in between.

In short, if it does not impact the expected behavior of httpd I would hope
that dropping support for openssl-0.9.X will improve the product and be
a motivator for upgrading, rather than a limiting factor. (Oh how I love my
pink glasses :) )

On Fri, May 8, 2015 at 2:29 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 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 

Re: Looking ahead to 2.4.13 / 2.2.30

[William A Rowe Jr]

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.

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

[Yann Ylavic]

On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic ylavic@gmail.com wrote:

   *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by
  allowing custom parameters to be configured via SSLCertificateFile,
  and by adding standardized DH parameters for 1024/2048/3072/4096 bits.
  Unless custom parameters are configured, the standardized parameters
  are applied based on the certificate's RSA/DSA key size. [Kaspar Brand]

I forgot to mention that this might potentially break some clients
(Java 7 and earlier only?), as noted in the docs/faq changes.
These expect 1024 bits DH params prime lengths whatever the
certificate's modulus' length is...
Should we have a special (2.2.x only?) directive to help mitigate the
possible regression (e.g. to force 1024 primes max only, default?), or
is the documented workaround enough (i.e. add dhparams in the
configured SSLCertificateFile)?

BTW, I proposed [1] for backport in r1678107, having tested the patch
successfully for [E[C]]DH, with certificates (modulus) = 1024 bits,
and OpenSSL versions 0.9.7a, 0.9.8o, 1.0.1m and 1.0.2a.

[1] http://people.apache.org/~ylavic/httpd-2.2.x-mod_ssl-improved_EDH.patch

Re: Looking ahead to 2.4.13 / 2.2.30

[Yann Ylavic]

+1

On Thu, May 7, 2015 at 6:45 PM, William A Rowe Jr wr...@rowe-clan.net wrote:
 Looking at the proposals in RFC 7525, I'm thinking this is a good time to
 re-sync
 httpd to these guidelines, even if it defers these releases by a week.
 WDYT?

 Bill

 On Fri, May 1, 2015 at 6:42 AM, Jim Jagielski j...@jagunet.com wrote:

 Yeah... I was gonna propose that once I had the weekend
 to take a more in-depth look at 2.4... But I am +1 for
 a release v. soon.

 Yeah, I'll RM 2.4
  On Apr 30, 2015, at 5:52 PM, William A Rowe Jr wr...@rowe-clan.net
  wrote:
 
  On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr.
  wr...@rowe-clan.net wrote:
  On Tue, 31 Mar 2015 10:49:47 -0400
  Jim Jagielski j...@jagunet.com wrote:
 
   BTW: Would it make sense to consider a release of 2.4.13 in April
   to coincide w/ ApacheCon?
 
  We've historically produced a release at the beginning of the con.
  It worked really well when we would hackathon two days, then retire
  to do other con stuff for the balance of the event with a new
  release in the hopper looking for votes.
 
  I'd love to see us tag and roll releases based on our efforts
  throughout the entire gathering, sometime in that following week.
  I offer to TR an update of 2.2 as well to pick up any issues we
  resolve over the course of that week.
 
  It seems that we have 2 groups of good things to come out of ApacheCon,
  some immediate fixes for things like BSD project efforts, some pretty
  straightforward defects that have been resolved... and then there's a
  bunch
  of energy about enhancements and the h2 universe.
 
  In the short term, WDYT about giving the trees a week to settle, grab
  the
  low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this
  coming
  week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30
  in tandem.
 
  Concerns / observations / thoughts?
 
  Bill

Re: Looking ahead to 2.4.13 / 2.2.30

[William A Rowe Jr]

Looking at the proposals in RFC 7525, I'm thinking this is a good time to
re-sync
httpd to these guidelines, even if it defers these releases by a week.
WDYT?

Bill

On Fri, May 1, 2015 at 6:42 AM, Jim Jagielski j...@jagunet.com wrote:

 Yeah... I was gonna propose that once I had the weekend
 to take a more in-depth look at 2.4... But I am +1 for
 a release v. soon.

 Yeah, I'll RM 2.4
  On Apr 30, 2015, at 5:52 PM, William A Rowe Jr wr...@rowe-clan.net
 wrote:
 
  On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. wr...@rowe-clan.net
 wrote:
  On Tue, 31 Mar 2015 10:49:47 -0400
  Jim Jagielski j...@jagunet.com wrote:
 
   BTW: Would it make sense to consider a release of 2.4.13 in April
   to coincide w/ ApacheCon?
 
  We've historically produced a release at the beginning of the con.
  It worked really well when we would hackathon two days, then retire
  to do other con stuff for the balance of the event with a new
  release in the hopper looking for votes.
 
  I'd love to see us tag and roll releases based on our efforts
  throughout the entire gathering, sometime in that following week.
  I offer to TR an update of 2.2 as well to pick up any issues we
  resolve over the course of that week.
 
  It seems that we have 2 groups of good things to come out of ApacheCon,
  some immediate fixes for things like BSD project efforts, some pretty
  straightforward defects that have been resolved... and then there's a
 bunch
  of energy about enhancements and the h2 universe.
 
  In the short term, WDYT about giving the trees a week to settle, grab the
  low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this
 coming
  week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30
  in tandem.
 
  Concerns / observations / thoughts?
 
  Bill

Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

[Yann Ylavic]

I'd like to propose those 2.4.x CHANGES (r1542327+r1569005+r1542327)
for backport to 2.2.x (in reverse order):

  *) mod_ssl: Fix tmp DH parameter leak, adjust selection to prefer
 larger keys and support up to 8192-bit keys.  [Ruediger Pluem,
 Joe Orton]

  *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by
 allowing custom parameters to be configured via SSLCertificateFile,
 and by adding standardized DH parameters for 1024/2048/3072/4096 bits.
 Unless custom parameters are configured, the standardized parameters
 are applied based on the certificate's RSA/DSA key size. [Kaspar Brand]

  *) mod_ssl, configure: Require OpenSSL 0.9.8a or later. [Kaspar Brand]

  *) mod_ssl: drop support for export-grade ciphers with ephemeral RSA
 keys, and unconditionally disable aNULL, eNULL and EXP ciphers
 (not overridable via SSLCipherSuite). [Kaspar Brand]

or at least partly.

Beyond the (problematic?) requirement on OpenSSL 0.9.8a (discussed
below), and what may look like an improvement only (first one), there
are also security considerations:
- ephemeral DH keys (for EDH ciphers) are currently limited to 1024
bits in 2.2.x, so with 2048 bits or more certificates (quite
recommended today), one should use its own dhparams for (E)DH ciphers,
- ecparams loadable from certificate allow to configure the curve/key
(plus SSL_CTX_set_ecdh_auto() when openssl = 1.0.2),
- export grade ciphers (removed from openssl's maintained versions)
are still in use with default/general configurations (FREAK, ...).

Regarding requirement on OpenSSL 0.9.8a (what's the actual requirement
in 2.2.x?), if that's really a stopper, it only concerns the use of
get_rfc{2409,3526}_prime_{1024,2048,..}() introduced in 0.9.8a
(AFAICT), and we could eventually include (statically) that primes in
the code for versions  0.9.8a.
But is there real 2.2.x user with OpenSSL  0.9.8a?

Also, those changes are effective since 2.4.7, and hence are quite
largely tested already.

Any pros/cons/comments before I try to resolve (hopefully) small conflicts?

Regards,
Yann.

Re: Looking ahead to 2.4.13 / 2.2.30

[Yann Ylavic]

On Tue, May 5, 2015 at 3:08 PM, Eric Covener cove...@gmail.com wrote:
 On Tue, May 5, 2015 at 9:03 AM, Yann Ylavic ylavic@gmail.com wrote:
 But is there real 2.2.x user with OpenSSL  0.9.8a?

 I'm no expert (we use a proprietary toolkit and SSL module where I
 spend most of my time), but that seems like quite an extreme thing to
 preserve in 2.2.x.

OK, as I said this is not so hard (at first glance) to avoid the use
of new functions for the backport.

 Maybe worth a separate thread though to shake out
 anyone with a stake in preserving it.

Agreed, done with Possible mod_ssl's backports to 2.2.x? (was:
Looking ahead to 2.4.13 / 2.2.30).
Thanks.

.

Re: Looking ahead to 2.4.13 / 2.2.30

[Eric Covener]

On Tue, May 5, 2015 at 9:03 AM, Yann Ylavic ylavic@gmail.com wrote:
 But is there real 2.2.x user with OpenSSL  0.9.8a?

I'm no expert (we use a proprietary toolkit and SSL module where I
spend most of my time), but that seems like quite an extreme thing to
preserve in 2.2.x.  Maybe worth a separate thread though to shake out
anyone with a stake in preserving it.

Re: Looking ahead to 2.4.13 / 2.2.30

[Yann Ylavic]

On Thu, Apr 30, 2015 at 11:52 PM, William A Rowe Jr wr...@rowe-clan.net wrote:

 Concerns / observations / thoughts?

I'd like to propose those 2.4.x CHANGES (r1542327+r1569005+r1542327)
for backport to 2.2.x (in reverse order):

  *) mod_ssl: Fix tmp DH parameter leak, adjust selection to prefer
 larger keys and support up to 8192-bit keys.  [Ruediger Pluem,
 Joe Orton]

  *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by
 allowing custom parameters to be configured via SSLCertificateFile,
 and by adding standardized DH parameters for 1024/2048/3072/4096 bits.
 Unless custom parameters are configured, the standardized parameters
 are applied based on the certificate's RSA/DSA key size. [Kaspar Brand]

  *) mod_ssl, configure: Require OpenSSL 0.9.8a or later. [Kaspar Brand]

  *) mod_ssl: drop support for export-grade ciphers with ephemeral RSA
 keys, and unconditionally disable aNULL, eNULL and EXP ciphers
 (not overridable via SSLCipherSuite). [Kaspar Brand]

or at least partly.

Beyond the (problematic?) requirement on OpenSSL 0.9.8a (discussed
below), and what may look like an improvement only (first one), there
are also security considerations:
- ephemeral DH keys (for EDH ciphers) are currently limited to 1024
bits in 2.2.x, so with 2048 bits or more certificates (quite
recommended today), one should use its own dhparams for (E)DH ciphers,
- ecparams loadable from certificate allow to configure the curve/key
(plus SSL_CTX_set_ecdh_auto() when openssl = 1.0.2),
- export grade ciphers (removed from openssl's maintained versions)
are still in use with default/general configurations (FREAK, ...).

Regarding requirement on OpenSSL 0.9.8a (what's the actual requirement
in 2.2.x?), if that's really a stopper, it only concerns the use of
get_rfc{2409,3526}_prime_{1024,2048,..}() introduced in 0.9.8a
(AFAICT), and we could eventually include (statically) that primes in
the code for versions  0.9.8a.
But is there real 2.2.x user with OpenSSL  0.9.8a?

Also, those changes are effective since 2.4.7, and hence are quite
largely tested already.

Any pros/cons/comments before I try to resolve (hopefully) small conflicts?

Regards,
Yann.

Re: Looking ahead to 2.4.13 / 2.2.30

[William A Rowe Jr]

On May 5, 2015 4:31 PM, olli hauer oha...@gmx.de wrote:

 Perhaps it is also a good time do kick SSLv2 support from 2.2.x ;)

We are deliberately not that disruptive to users.  Our goal is to push more
secure code at users, but not at the risk of their electing to not update,
due to such blunt force.  A subversion update should never break a working
installation.

Strongly -1.

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

[Yann Ylavic]

Please note that the primes constants in modules/ssl/ssl_engine_dh.c
are from openssl/crypto/bn/bn_const.c.
FWIW, attached is a (stripped) diff between the two files that shows
constants are the same...

On Tue, May 5, 2015 at 7:12 PM, Yann Ylavic ylavic@gmail.com wrote:
 Possible backport patch attached.

 On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic ylavic@gmail.com wrote:
 I'd like to propose those 2.4.x CHANGES (r1542327+r1569005+r1542327)
 for backport to 2.2.x (in reverse order):

   *) mod_ssl: Fix tmp DH parameter leak, adjust selection to prefer
  larger keys and support up to 8192-bit keys.  [Ruediger Pluem,
  Joe Orton]

   *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by
  allowing custom parameters to be configured via SSLCertificateFile,
  and by adding standardized DH parameters for 1024/2048/3072/4096 bits.
  Unless custom parameters are configured, the standardized parameters
  are applied based on the certificate's RSA/DSA key size. [Kaspar Brand]

   *) mod_ssl, configure: Require OpenSSL 0.9.8a or later. [Kaspar Brand]

   *) mod_ssl: drop support for export-grade ciphers with ephemeral RSA
  keys, and unconditionally disable aNULL, eNULL and EXP ciphers
  (not overridable via SSLCipherSuite). [Kaspar Brand]

 or at least partly.

 Beyond the (problematic?) requirement on OpenSSL 0.9.8a (discussed
 below), and what may look like an improvement only (first one), there
 are also security considerations:
 - ephemeral DH keys (for EDH ciphers) are currently limited to 1024
 bits in 2.2.x, so with 2048 bits or more certificates (quite
 recommended today), one should use its own dhparams for (E)DH ciphers,
 - ecparams loadable from certificate allow to configure the curve/key
 (plus SSL_CTX_set_ecdh_auto() when openssl = 1.0.2),
 - export grade ciphers (removed from openssl's maintained versions)
 are still in use with default/general configurations (FREAK, ...).

 Regarding requirement on OpenSSL 0.9.8a (what's the actual requirement
 in 2.2.x?), if that's really a stopper, it only concerns the use of
 get_rfc{2409,3526}_prime_{1024,2048,..}() introduced in 0.9.8a
 (AFAICT), and we could eventually include (statically) that primes in
 the code for versions  0.9.8a.
 But is there real 2.2.x user with OpenSSL  0.9.8a?

 Also, those changes are effective since 2.4.7, and hence are quite
 largely tested already.

 Any pros/cons/comments before I try to resolve (hopefully) small conflicts?

 Regards,
 Yann.
--- openssl-1.0.1m/crypto/bn/bn_const.c 2015-03-19 14:19:00.0 +0100
+++ modules/ssl/ssl_engine_dh.c 2015-05-05 19:27:03.689262006 +0200
@@ -1,48 +1,116 @@
[]
-/*-
+/* END GENERATED SECTION-- */
+
+/*
  * Second Oakley Default Group from RFC2409, section 6.2.
  *
  * The prime is: 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
  *
  * RFC2409 specifies a generator of 2.
- * RFC2412 specifies a generator of 22.
  */
-
-BIGNUM *get_rfc2409_prime_1024(BIGNUM *bn)
-{
-static const unsigned char RFC2409_PRIME_1024[] = {
+static const unsigned char dh1024_p[] = {
 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
 0xC9, 0x0F, 0xDA, 0xA2, 0x21, 0x68, 0xC2, 0x34,
 0xC4, 0xC6, 0x62, 0x8B, 0x80, 0xDC, 0x1C, 0xD1,
@@ -60,60 +128,24 @@
 0x49, 0x28, 0x66, 0x51, 0xEC, 0xE6, 0x53, 0x81,
 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
 };
-return BN_bin2bn(RFC2409_PRIME_1024, sizeof(RFC2409_PRIME_1024), bn);
+static const unsigned char dh1024_g[] = {
+0x02,
+};
[]
-/*-
+/*
  * 2048-bit MODP Group from RFC3526, Section 3.
  *
  * The prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
  *
  * RFC3526 specifies a generator of 2.
  */
-
-BIGNUM *get_rfc3526_prime_2048(BIGNUM *bn)
-{
-static const unsigned char RFC3526_PRIME_2048[] = {
+static const unsigned char dh2048_p[] = {
 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
 0xC9, 0x0F, 0xDA, 0xA2, 0x21, 0x68, 0xC2, 0x34,
 0xC4, 0xC6, 0x62, 0x8B, 0x80, 0xDC, 0x1C, 0xD1,
@@ -147,20 +179,24 @@
 0x15, 0x72, 0x8E, 0x5A, 0x8A, 0xAC, 0xAA, 0x68,
 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
 };
-return BN_bin2bn(RFC3526_PRIME_2048, sizeof(RFC3526_PRIME_2048), bn);
+static const unsigned char dh2048_g[] = {
+0x02,
+};
[]
-/*-
+/*
  * 3072-bit MODP Group from RFC3526, Section 4.
  *
  * The prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }
  *
  * RFC3526 specifies a generator of 2.
  */
-
-BIGNUM *get_rfc3526_prime_3072(BIGNUM *bn)
-{
-static const unsigned char RFC3526_PRIME_3072[] = {
+static const unsigned char dh3072_p[] = {
 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
 0xC9, 0x0F, 0xDA, 0xA2, 0x21, 0x68, 0xC2, 0x34,
 0xC4, 0xC6, 0x62, 0x8B, 0x80, 0xDC, 0x1C, 0xD1,
@@ -210,20 +246,24 @@
 0x4B, 0x82, 0xD1, 0x20, 0xA9, 0x3A, 0xD2, 0xCA,
 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
 };
-return 

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

[Yann Ylavic]

Possible backport patch attached.

On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic ylavic@gmail.com wrote:
 I'd like to propose those 2.4.x CHANGES (r1542327+r1569005+r1542327)
 for backport to 2.2.x (in reverse order):

   *) mod_ssl: Fix tmp DH parameter leak, adjust selection to prefer
  larger keys and support up to 8192-bit keys.  [Ruediger Pluem,
  Joe Orton]

   *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by
  allowing custom parameters to be configured via SSLCertificateFile,
  and by adding standardized DH parameters for 1024/2048/3072/4096 bits.
  Unless custom parameters are configured, the standardized parameters
  are applied based on the certificate's RSA/DSA key size. [Kaspar Brand]

   *) mod_ssl, configure: Require OpenSSL 0.9.8a or later. [Kaspar Brand]

   *) mod_ssl: drop support for export-grade ciphers with ephemeral RSA
  keys, and unconditionally disable aNULL, eNULL and EXP ciphers
  (not overridable via SSLCipherSuite). [Kaspar Brand]

 or at least partly.

 Beyond the (problematic?) requirement on OpenSSL 0.9.8a (discussed
 below), and what may look like an improvement only (first one), there
 are also security considerations:
 - ephemeral DH keys (for EDH ciphers) are currently limited to 1024
 bits in 2.2.x, so with 2048 bits or more certificates (quite
 recommended today), one should use its own dhparams for (E)DH ciphers,
 - ecparams loadable from certificate allow to configure the curve/key
 (plus SSL_CTX_set_ecdh_auto() when openssl = 1.0.2),
 - export grade ciphers (removed from openssl's maintained versions)
 are still in use with default/general configurations (FREAK, ...).

 Regarding requirement on OpenSSL 0.9.8a (what's the actual requirement
 in 2.2.x?), if that's really a stopper, it only concerns the use of
 get_rfc{2409,3526}_prime_{1024,2048,..}() introduced in 0.9.8a
 (AFAICT), and we could eventually include (statically) that primes in
 the code for versions  0.9.8a.
 But is there real 2.2.x user with OpenSSL  0.9.8a?

 Also, those changes are effective since 2.4.7, and hence are quite
 largely tested already.

 Any pros/cons/comments before I try to resolve (hopefully) small conflicts?

 Regards,
 Yann.
Index: CHANGES
===
--- CHANGES	(revision 1677836)
+++ CHANGES	(working copy)
@@ -1,7 +1,15 @@
  -*- coding: utf-8 -*-
 Changes with Apache 2.2.30
 
+  *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by
+ allowing custom parameters to be configured via SSLCertificateFile,
+ and by adding standardized DH parameters for 1024/2048/3072/4096 bits.
+ Unless custom parameters are configured, the standardized parameters
+ are applied based on the certificate's RSA/DSA key size.
 
+  *) mod_ssl: drop support for export-grade ciphers with ephemeral RSA
+ keys, and unconditionally disable aNULL, eNULL and EXP ciphers
+ (not overridable via SSLCipherSuite). [Kaspar Brand]
 
 Changes with Apache 2.2.29
 
Index: docs/manual/mod/mod_ssl.xml
===
--- docs/manual/mod/mod_ssl.xml	(revision 1677836)
+++ docs/manual/mod/mod_ssl.xml	(working copy)
@@ -691,6 +691,15 @@ prefixes are:/p
 licode-/code: remove cipher from list (can be added later again)/li
 licode!/code: kill cipher from list completely (can strongnot/strong be added later again)/li
 /ul
+
+note
+titlecodeaNULL/code, codeeNULL/code and codeEXP/code
+ciphers are always disabled/title
+pBeginning with version 2.2.30, null and export-grade
+ciphers are always disabled, as mod_ssl unconditionally prepends any supplied
+cipher suite string with code!aNULL:!eNULL:!EXP:/code at initialization./p
+/note
+
 pA simpler way to look at all of this is to use the ``codeopenssl ciphers
 -v/code'' command which provides a nice way to successively create the
 correct emcipher-spec/em string. The default emcipher-spec/em string
@@ -767,12 +776,34 @@ SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW
 
 usage
 p
-This directive points to the PEM-encoded Certificate file for the server and
-optionally also to the corresponding RSA or DSA Private Key file for it
-(contained in the same file). If the contained Private Key is encrypted the
-Pass Phrase dialog is forced at startup time. This directive can be used up to
-three times (referencing different filenames) when both a RSA, a DSA, and an
-ECC based server certificate is used in parallel./p
+This directive points to the file with the PEM-encoded certificate,
+optionally also the corresponding private key, and - beginning with
+version 2.2.30 - DH parameters and/or an EC curve name
+for ephemeral keys (as generated by codeopenssl dhparam/code
+and codeopenssl ecparam/code, respectively). If the private key
+is encrypted, the pass phrase dialog is forced at startup time.
+/p
+p
+This directive can be used up to three times 

Re: Looking ahead to 2.4.13 / 2.2.30

[William A Rowe Jr]

On Tue, May 5, 2015 at 8:08 AM, Eric Covener cove...@gmail.com wrote:

 On Tue, May 5, 2015 at 9:03 AM, Yann Ylavic ylavic@gmail.com wrote:
  But is there real 2.2.x user with OpenSSL  0.9.8a?

 I'm no expert (we use a proprietary toolkit and SSL module where I
 spend most of my time), but that seems like quite an extreme thing to
 preserve in 2.2.x.  Maybe worth a separate thread though to shake out
 anyone with a stake in preserving it.


Agreed.  Wouldn't a ./configure time warning suffice?

I also disagree with disabling 0.9.7 entirely on a legacy branch.

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

[Eric Covener]

On Tue, May 5, 2015 at 3:06 PM, Hanno Böck ha...@hboeck.de wrote:
 I haven't used apache 2.2, but isn't OCSP stapling support still
 missing there?

 I think if you're already working on backporting important TLS features
 that should certainly go with them.


My own line for 2.2 would be drawn somewhere between Yann's proposal
and things like OCSP stapling.   I think the former is more
fundamental/hardening and a better fit for the aging release.

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

[Hanno Böck]

I haven't used apache 2.2, but isn't OCSP stapling support still
missing there?

I think if you're already working on backporting important TLS features
that should certainly go with them.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpNXAgtjh1Er.pgp
Description: OpenPGP digital signature

Re: Looking ahead to 2.4.13 / 2.2.30

[olli hauer]

On 2015-05-05 15:03, Yann Ylavic wrote:
 On Thu, Apr 30, 2015 at 11:52 PM, William A Rowe Jr wr...@rowe-clan.net 
 wrote:

 Concerns / observations / thoughts?
 
 I'd like to propose those 2.4.x CHANGES (r1542327+r1569005+r1542327)
 for backport to 2.2.x (in reverse order):
 
   *) mod_ssl: Fix tmp DH parameter leak, adjust selection to prefer
  larger keys and support up to 8192-bit keys.  [Ruediger Pluem,
  Joe Orton]
 
   *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by
  allowing custom parameters to be configured via SSLCertificateFile,
  and by adding standardized DH parameters for 1024/2048/3072/4096 bits.
  Unless custom parameters are configured, the standardized parameters
  are applied based on the certificate's RSA/DSA key size. [Kaspar Brand]
 
   *) mod_ssl, configure: Require OpenSSL 0.9.8a or later. [Kaspar Brand]
 
   *) mod_ssl: drop support for export-grade ciphers with ephemeral RSA
  keys, and unconditionally disable aNULL, eNULL and EXP ciphers
  (not overridable via SSLCipherSuite). [Kaspar Brand]
 
 or at least partly.
 

Perhaps it is also a good time do kick SSLv2 support from 2.2.x ;)

Re: Looking ahead to 2.4.13 / 2.2.30

[Brian J. France]

While you are in mod_dav, could you review these patches and see if it makes 
sense to add them?

httpd-2.2.x : http://www.brianfrance.com/software/apache/dav/mod_dav_fs.diff.22
httpd-2.4.x : http://www.brianfrance.com/software/apache/dav/mod_dav_fs.diff.24

We have been running these for a while at work, just haven't had free time to 
send them.

Thanks!

Brian


 On May 1, 2015, at 3:29 PM, Ben Reser b...@reser.org wrote:
 
 On 4/30/15 2:52 PM, William A Rowe Jr wrote:
 It seems that we have 2 groups of good things to come out of ApacheCon,
 some immediate fixes for things like BSD project efforts, some pretty
 straightforward defects that have been resolved... and then there's a bunch
 of energy about enhancements and the h2 universe.
 
 In the short term, WDYT about giving the trees a week to settle, grab the
 low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming
 week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 
 in tandem.
 
 Concerns / observations / thoughts?
 
 I have a mod_dav fix that really ought to be in the next 2.4 release.  I'll 
 get
 it committed and nominated sometime this weekend.
 

Re: Looking ahead to 2.4.13 / 2.2.30

[Ben Reser]

On 5/4/15 7:40 AM, Brian J. France wrote:
 While you are in mod_dav, could you review these patches and see if it makes 
 sense to add them?
 
 httpd-2.2.x : 
 http://www.brianfrance.com/software/apache/dav/mod_dav_fs.diff.22
 httpd-2.4.x : 
 http://www.brianfrance.com/software/apache/dav/mod_dav_fs.diff.24
 
 We have been running these for a while at work, just haven't had free time to 
 send them.

Can you sure what issue you're trying to work around with those?  In and of
themselves they look alright but I'd like to understand what motivated the 
change.

Re: Looking ahead to 2.4.13 / 2.2.30

[Jim Jagielski]

Thx!

 On May 1, 2015, at 3:29 PM, Ben Reser b...@reser.org wrote:
 
 On 4/30/15 2:52 PM, William A Rowe Jr wrote:
 It seems that we have 2 groups of good things to come out of ApacheCon,
 some immediate fixes for things like BSD project efforts, some pretty
 straightforward defects that have been resolved... and then there's a bunch
 of energy about enhancements and the h2 universe.
 
 In the short term, WDYT about giving the trees a week to settle, grab the
 low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming
 week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 
 in tandem.
 
 Concerns / observations / thoughts?
 
 I have a mod_dav fix that really ought to be in the next 2.4 release.  I'll 
 get
 it committed and nominated sometime this weekend.
 

Re: Looking ahead to 2.4.13 / 2.2.30

[Ben Reser]

On 5/3/15 8:05 AM, Jim Jagielski wrote:
 Thx!
 
 On May 1, 2015, at 3:29 PM, Ben Reser b...@reser.org wrote:

 On 4/30/15 2:52 PM, William A Rowe Jr wrote:
 It seems that we have 2 groups of good things to come out of ApacheCon,
 some immediate fixes for things like BSD project efforts, some pretty
 straightforward defects that have been resolved... and then there's a bunch
 of energy about enhancements and the h2 universe.

 In the short term, WDYT about giving the trees a week to settle, grab the
 low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming
 week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 
 in tandem.

 Concerns / observations / thoughts?

 I have a mod_dav fix that really ought to be in the next 2.4 release.  I'll 
 get
 it committed and nominated sometime this weekend.

My fix is committed and backports nominated.  If someone can look at them it'd
be appreciated.

Re: Looking ahead to 2.4.13 / 2.2.30

[Ben Reser]

On 4/30/15 2:52 PM, William A Rowe Jr wrote:
 It seems that we have 2 groups of good things to come out of ApacheCon,
 some immediate fixes for things like BSD project efforts, some pretty
 straightforward defects that have been resolved... and then there's a bunch
 of energy about enhancements and the h2 universe.
 
 In the short term, WDYT about giving the trees a week to settle, grab the
 low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming
 week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 
 in tandem.
 
 Concerns / observations / thoughts?

I have a mod_dav fix that really ought to be in the next 2.4 release.  I'll get
it committed and nominated sometime this weekend.

Re: Looking ahead to 2.4.13 / 2.2.30

[Jim Jagielski]

Yeah... I was gonna propose that once I had the weekend
to take a more in-depth look at 2.4... But I am +1 for
a release v. soon.

Yeah, I'll RM 2.4
 On Apr 30, 2015, at 5:52 PM, William A Rowe Jr wr...@rowe-clan.net wrote:
 
 On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. wr...@rowe-clan.net 
 wrote:
 On Tue, 31 Mar 2015 10:49:47 -0400
 Jim Jagielski j...@jagunet.com wrote:
 
  BTW: Would it make sense to consider a release of 2.4.13 in April
  to coincide w/ ApacheCon?
 
 We've historically produced a release at the beginning of the con.
 It worked really well when we would hackathon two days, then retire
 to do other con stuff for the balance of the event with a new
 release in the hopper looking for votes.
 
 I'd love to see us tag and roll releases based on our efforts
 throughout the entire gathering, sometime in that following week.
 I offer to TR an update of 2.2 as well to pick up any issues we
 resolve over the course of that week.
 
 It seems that we have 2 groups of good things to come out of ApacheCon,
 some immediate fixes for things like BSD project efforts, some pretty
 straightforward defects that have been resolved... and then there's a bunch
 of energy about enhancements and the h2 universe.
 
 In the short term, WDYT about giving the trees a week to settle, grab the
 low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming
 week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 
 in tandem.
 
 Concerns / observations / thoughts?
 
 Bill

Looking ahead to 2.4.13 / 2.2.30

[William A Rowe Jr]

On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. wr...@rowe-clan.net
wrote:

 On Tue, 31 Mar 2015 10:49:47 -0400
 Jim Jagielski j...@jagunet.com wrote:

  BTW: Would it make sense to consider a release of 2.4.13 in April
  to coincide w/ ApacheCon?

 We've historically produced a release at the beginning of the con.
 It worked really well when we would hackathon two days, then retire
 to do other con stuff for the balance of the event with a new
 release in the hopper looking for votes.

 I'd love to see us tag and roll releases based on our efforts
 throughout the entire gathering, sometime in that following week.
 I offer to TR an update of 2.2 as well to pick up any issues we
 resolve over the course of that week.


It seems that we have 2 groups of good things to come out of ApacheCon,
some immediate fixes for things like BSD project efforts, some pretty
straightforward defects that have been resolved... and then there's a bunch
of energy about enhancements and the h2 universe.

In the short term, WDYT about giving the trees a week to settle, grab the
low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming
week?  Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30
in tandem.

Concerns / observations / thoughts?

Bill