Re: Looking ahead to 2.4.13 / 2.2.30
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
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
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)
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
+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
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)
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
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
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
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
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)
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)
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
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)
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)
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
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
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
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
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
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
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
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
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