You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2015/05/05 15:14:34 UTC
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: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to
2.4.13 / 2.2.30)
Posted by Eric Covener <co...@gmail.com>.
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)
Posted by Hanno Böck <ha...@hboeck.de>.
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: hanno@hboeck.de
GPG: BBB51E42
Re: SSL/TLS best current practice
Posted by Noel Butler <no...@ausics.net>.
Thanks Christian.
On 11/05/2015 01:57, Christian Seiler wrote:
> On 05/10/2015 03:26 AM, Noel Butler wrote:
>
>> Can any SUSE and debian users confirm the current supported stable
>> release supports 1.2?
>
> Currently, three Debian releases are still supported:
>
> - Debian Jessie (current stable)
> * released 2015-04
> - main support will end 2018-05
> - possibly LTS until 2020-04
> * ships Apache 2.4.10
> * ships OpenSSL 1.0.1k + patches
> * supports TLS v1.2 chipers
>
> - Debian Wheezy ("oldstable")
> * release 2013-05
> - main support will end 2016-02
> - probably LTS until 2018-05
> * ships Apache 2.2.22 + patches
> * ships OpenSSL 1.0.1e + patches
> * supports TLS v1.2 chipers
>
> - Debian Squeeze ("oldoldstable")
> * release 2011-02
> * only x86 architectures still supported ("long term support", LTS)
> and there not all packages (but Apache and OpenSSL still are)
> - LTS will end 2016-02
> * ships Apache 2.2.16 + patches
> * ships OpenSSL 0.9.8o + patches
> * only supports SSLv3 chipers (esp. no SHA2 family hashes)
>
> Note that Debian Jessie's Apache default configuration already comes with:
>
> SSLCipherSuite HIGH:!aNULL
> SSLProtocol all -SSLv3
>
> Christian
Re: SSL/TLS best current practice
Posted by Christian Seiler <ch...@gmx.net>.
On 05/10/2015 03:26 AM, Noel Butler wrote:
> Can any SUSE and debian users confirm the current supported stable
> release supports 1.2?
Currently, three Debian releases are still supported:
- Debian Jessie (current stable)
* released 2015-04
- main support will end 2018-05
- possibly LTS until 2020-04
* ships Apache 2.4.10
* ships OpenSSL 1.0.1k + patches
* supports TLS v1.2 chipers
- Debian Wheezy ("oldstable")
* release 2013-05
- main support will end 2016-02
- probably LTS until 2018-05
* ships Apache 2.2.22 + patches
* ships OpenSSL 1.0.1e + patches
* supports TLS v1.2 chipers
- Debian Squeeze ("oldoldstable")
* release 2011-02
* only x86 architectures still supported ("long term support", LTS)
and there not all packages (but Apache and OpenSSL still are)
- LTS will end 2016-02
* ships Apache 2.2.16 + patches
* ships OpenSSL 0.9.8o + patches
* only supports SSLv3 chipers (esp. no SHA2 family hashes)
Note that Debian Jessie's Apache default configuration already comes with:
SSLCipherSuite HIGH:!aNULL
SSLProtocol all -SSLv3
Christian
Re: SSL/TLS best current practice
Posted by Noel Butler <no...@ausics.net>.
On 10/05/2015 11:08, Reindl Harald wrote:
> Am 10.05.2015 um 03:02 schrieb Noel Butler:
>
>> Either way, using slackware on all my servers its trivial since the
>> distro keeps pretty much up to date by design - unlike RH/debian and
>> their kiddy versions who bring out new releases with 2+yo libs and other
>> goodies, I'd just hesitate to drop them, wait and see whats capable in
>> their current enterprise releases when the time comes to make that
>> decision, since RH is most used enterprise release, I'm going to
>> contradict myself here - since it's always been my belief that upstreams
>> should never base their decisions on downstreams (like ASF does WRT
>> deprecating 2.2) but if RH for example's new release at the time doesn't
>> support 1.2, its pointless dropping 1.0/1.1
>
> Redhat already supports 1.2, not only thew new RHEL7, also up-to-date RHEL6, only RHEL5 which is still supported is behind and that's just because that's the whole purpose of a LTS distribution
Thats good to know, thanks you.
Can any SUSE and debian users confirm the current supported stable
release supports 1.2?
If so, then by objection is withdrawn Bill :)
Re: SSL/TLS best current practice
Posted by Reindl Harald <h....@thelounge.net>.
Am 10.05.2015 um 03:02 schrieb Noel Butler:
> Either way, using slackware on all my servers its trivial since the
> distro keeps pretty much up to date by design - unlike RH/debian and
> their kiddy versions who bring out new releases with 2+yo libs and other
> goodies, I'd just hesitate to drop them, wait and see whats capable in
> their current enterprise releases when the time comes to make that
> decision, since RH is most used enterprise release, I'm going to
> contradict myself here - since it's always been my belief that upstreams
> should never base their decisions on downstreams (like ASF does WRT
> deprecating 2.2) but if RH for example's new release at the time doesn't
> support 1.2, its pointless dropping 1.0/1.1
Redhat already supports 1.2, not only thew new RHEL7, also up-to-date
RHEL6, only RHEL5 which is still supported is behind and that's just
because that's the whole purpose of a LTS distribution
[root@localhost:~]$ rpm -q openssl
openssl-1.0.1e-30.el6.8.x86_64
[root@localhost:~]$ openssl ciphers -v
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256)
Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH
Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)
Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128)
Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH
Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)
Mac=SHA256
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
KRB5-IDEA-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=SHA1
KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1
KRB5-IDEA-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=IDEA(128) Mac=MD5
KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1
KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
Re: SSL/TLS best current practice
Posted by Noel Butler <no...@ausics.net>.
On 07/05/2015 12:17, William A Rowe Jr wrote:
> On May 6, 2015 9:09 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
>>
>>
>> On May 6, 2015 8:12 PM, "Noel Butler" <no...@ausics.net> wrote:
>> >
>> > On 07/05/2015 09:22, William A Rowe Jr wrote:
>> >>
>> >>
>> >> For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt the recommended cipher list illustrated below (!SSLv3) in the default extra/httpd-ssl.conf source, following the SHOULD recommendations.
>> >
>> > unless trunk is for the 2.6 release -1
>>
>> Noel, that is precisely the purpose of trunk, always. The 'next' release. Might be 2.6, might be called 3.0.
>
> And if you pay particularly close attention, you'll note that trunk already presents itself as 2.5.0-dev, its version number when we first attempt an alpha toward 2.6 or 3.0, sometime is the future.
yes, I had a bad (few) day then - flu
Either way, using slackware on all my servers its trivial since the
distro keeps pretty much up to date by design - unlike RH/debian and
their kiddy versions who bring out new releases with 2+yo libs and other
goodies, I'd just hesitate to drop them, wait and see whats capable in
their current enterprise releases when the time comes to make that
decision, since RH is most used enterprise release, I'm going to
contradict myself here - since it's always been my belief that upstreams
should never base their decisions on downstreams (like ASF does WRT
deprecating 2.2) but if RH for example's new release at the time doesn't
support 1.2, its pointless dropping 1.0/1.1
Dont get me wrong, I think RH, debian, and to a point even SUSE, are the
ones who need to pull their finger out and modernise (been 10 years
since I touched/looked at a BSD box so wont comment on the state of
them)
But... maybe... you are right... making the statement now that come 2.6
(I'd rather see it in a new major - like 3.x) that if those guys cant
get their act together by then, they got nobody to blame but themselves.
Re: SSL/TLS best current practice
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On May 6, 2015 9:09 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
>
>
> On May 6, 2015 8:12 PM, "Noel Butler" <no...@ausics.net> wrote:
> >
> > On 07/05/2015 09:22, William A Rowe Jr wrote:
> >>
> >>
> >> For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply
adopt the recommended cipher list illustrated below (!SSLv3) in the default
extra/httpd-ssl.conf source, following the SHOULD recommendations.
> >
> > unless trunk is for the 2.6 release -1
>
> Noel, that is precisely the purpose of trunk, always. The 'next'
release. Might be 2.6, might be called 3.0.
And if you pay particularly close attention, you'll note that trunk already
presents itself as 2.5.0-dev, its version number when we first attempt an
alpha toward 2.6 or 3.0, sometime is the future.
Re: SSL/TLS best current practice
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On May 6, 2015 8:12 PM, "Noel Butler" <no...@ausics.net> wrote:
>
> On 07/05/2015 09:22, William A Rowe Jr wrote:
>>
>>
>> For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply
adopt the recommended cipher list illustrated below (!SSLv3) in the default
extra/httpd-ssl.conf source, following the SHOULD recommendations.
>>
>
>
>
> unless trunk is for the 2.6 release -1
Noel, that is precisely the purpose of trunk, always. The 'next' release.
Might be 2.6, might be called 3.0.
We cherry pick fixes to backport all the time, but trunk exists to shape
the subsequent release.
> Since we are told, every time the discussion of abandoning 2.2.x comes
up, that too many distro's with LTS's and Enterprise versions still support
and maintain these antique versions, many admins do also require those
antique distro versions but elect to build current source of httpd, I would
then "-1" for removal of tls 1.0/1.1 (unless for the new "major" release
where I'd agree with it) - because if there systems are that old, they
"may" very well have issues with the removal of them, since their overall
system/ssl libs are going to also be antiques :)
Which is where you should direct your attention to backport proposals, on
2.4 as well as 2.2, since these are now adopted by users.
Re: SSL/TLS best current practice
Posted by Noel Butler <no...@ausics.net>.
On 07/05/2015 09:22, William A Rowe Jr wrote:
> For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt the recommended cipher list illustrated below (!SSLv3) in the default extra/httpd-ssl.conf source, following the SHOULD recommendations.
unless trunk is for the 2.6 release -1
Since we are told, every time the discussion of abandoning 2.2.x comes
up, that too many distro's with LTS's and Enterprise versions still
support and maintain these antique versions, many admins do also require
those antique distro versions but elect to build current source of
httpd, I would then "-1" for removal of tls 1.0/1.1 (unless for the new
"major" release where I'd agree with it) - because if there systems are
that old, they "may" very well have issues with the removal of them,
since their overall system/ssl libs are going to also be antiques :)
Re: SSL/TLS best current practice
Posted by Andy Wang <aw...@ptc.com>.
>>
>> Here's my proposed comment to inject in trunk/2.4/2.2 default httpd-ssl.conf
>> - any adjustments here?
>>
>> # httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers,
>> # while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
>
> +1
>
Agreed +1. That's nice and informative.
I couldn't tell from the discussion if this config was being pushed in
to 2.2. It is? If so, that's great. It'll help me justify pushing it
to our customer shipping installations.
Re: SSL/TLS best current practice
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, May 27, 2015 at 5:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Tue, May 26, 2015 at 11:45 AM, Andy Wang <aw...@ptc.com> wrote:
>>
>> I initially thought openssl disabled the NULL ones by default but when i
>> started playing with openssl cipher strings and saw them I got confused.
>> Didn't even consider that httpd did it automatically. Documenting it would
>> be a nice touch. Thanks for doing that.
>
>
> As it turns out, 0.9.2b disabled aNULL/eNULL by default.
Yes, if you don't specify any ciphersuite (ie. no SSLCipherSuite in httpd).
> Export ciphers are
> disabled by default as of 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
AFAICT, they are not even selectable (not in ALL and EXP is ignored)...
>
> Here's my proposed comment to inject in trunk/2.4/2.2 default httpd-ssl.conf
> - any adjustments here?
>
> # httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers,
> # while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
+1
Re: SSL/TLS best current practice
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, May 26, 2015 at 11:45 AM, Andy Wang <aw...@ptc.com> wrote:
>
> On 05/26/2015 11:25 AM, William A Rowe Jr wrote:
>
>> On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic <ylavic.dev@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> On Tue, May 26, 2015 at 5:29 PM, Andy Wang <awang@ptc.com
>> <ma...@ptc.com>> wrote:
>> >
>> >> # SSL Cipher Suite:
>> >> # List the ciphers that the client is permitted to negotiate.
>> >> # See the mod_ssl documentation for a complete list.
>> >> SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
>> >> SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
>> >
>> > !aNULL isn't needed?
>>
>> No since !aNULL:!eNULL:!EXP is forcibly added to the configured
>> ciphersuite.
>>
>>
>> A legitimate question, however. The example should document this IMHO.
>> Getting right on that.
>>
>>
> I initially thought openssl disabled the NULL ones by default but when i
> started playing with openssl cipher strings and saw them I got confused.
> Didn't even consider that httpd did it automatically. Documenting it would
> be a nice touch. Thanks for doing that.
>
As it turns out, 0.9.2b disabled aNULL/eNULL by default. Export ciphers
are disabled by default as of 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
Here's my proposed comment to inject in trunk/2.4/2.2 default
httpd-ssl.conf - any adjustments here?
# httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers,
# while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
Re: SSL/TLS best current practice
Posted by Andy Wang <aw...@ptc.com>.
On 05/26/2015 11:25 AM, William A Rowe Jr wrote:
> On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic <ylavic.dev@gmail.com
> <ma...@gmail.com>> wrote:
>
> On Tue, May 26, 2015 at 5:29 PM, Andy Wang <awang@ptc.com
> <ma...@ptc.com>> wrote:
> >
> >> # SSL Cipher Suite:
> >> # List the ciphers that the client is permitted to negotiate.
> >> # See the mod_ssl documentation for a complete list.
> >> SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
> >> SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
> >
> > !aNULL isn't needed?
>
> No since !aNULL:!eNULL:!EXP is forcibly added to the configured
> ciphersuite.
>
>
> A legitimate question, however. The example should document this IMHO.
> Getting right on that.
>
I initially thought openssl disabled the NULL ones by default but when i
started playing with openssl cipher strings and saw them I got confused.
Didn't even consider that httpd did it automatically. Documenting it
would be a nice touch. Thanks for doing that.
Andy
Re: SSL/TLS best current practice
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, May 26, 2015 at 10:45 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Tue, May 26, 2015 at 5:29 PM, Andy Wang <aw...@ptc.com> wrote:
> >
> >> # SSL Cipher Suite:
> >> # List the ciphers that the client is permitted to negotiate.
> >> # See the mod_ssl documentation for a complete list.
> >> SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
> >> SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
> >
> > !aNULL isn't needed?
>
> No since !aNULL:!eNULL:!EXP is forcibly added to the configured
> ciphersuite.
>
A legitimate question, however. The example should document this IMHO.
Getting right on that.
Re: SSL/TLS best current practice
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, May 26, 2015 at 5:29 PM, Andy Wang <aw...@ptc.com> wrote:
>
>
>> ---
>>
>> # SSL Cipher Suite:
>> # List the ciphers that the client is permitted to negotiate.
>> # See the mod_ssl documentation for a complete list.
>> SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
>> SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
>
>
> !aNULL isn't needed?
No since !aNULL:!eNULL:!EXP is forcibly added to the configured ciphersuite.
Re: SSL/TLS best current practice
Posted by Andy Wang <aw...@ptc.com>.
> ---
>
> # SSL Cipher Suite:
> # List the ciphers that the client is permitted to negotiate.
> # See the mod_ssl documentation for a complete list.
> SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
> SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
!aNULL isn't needed?
Re: SSL/TLS best current practice
Posted by Tim Bannister <is...@c8h10n4o2.org.uk>.
On 23 May 2015, at 12:50, Jeff Trawick <tr...@gmail.com> wrote:
>
> On 05/06/2015 07:22 PM, William A Rowe Jr wrote:
>> Here is my proposed global config for httpd.conf.in for 2.4 and 2.2, which I believe mirrors the 'MUST' of RFC 7525.
>
> So new default configs are improved, and that's great.
>
> Any joint interest in maintaining a "guide to implementing SSL/TLS best practices" in the documentation for those that don't normally see our latest/greatest default configuration and/or need some extra prose around it?
I can help with this.
--
Tim Bannister - isoma@c8h10n4o2.org.uk
Re: SSL/TLS best current practice
Posted by Jeff Trawick <tr...@gmail.com>.
On 05/06/2015 07:22 PM, William A Rowe Jr wrote:
> Here is my proposed global config for httpd.conf.in
> <http://httpd.conf.in> for 2.4 and 2.2, which I believe mirrors the
> 'MUST' of RFC 7525.
So new default configs are improved, and that's great.
Any joint interest in maintaining a "guide to implementing SSL/TLS best
practices" in the documentation for those that don't normally see our
latest/greatest default configuration and/or need some extra prose
around it?
A start would be:
* list source material for best practices
* describe how known tradeoffs (such as blocking old clients) are
accommodated in the specific configuration recommendations
* the actual configuration related to best SSL/TLS practices from our
current default SSL configs
* hints on how to configure these in our past releases as well as with
distributions that have their own idea of file layout/own defaults
Re: SSL/TLS best current practice
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Here is my proposed global config for httpd.conf.in for 2.4 and 2.2, which
I believe mirrors the 'MUST' of RFC 7525. This includes restoring the
SSLProtocol -SSLv3 for 2.4 so that it is plainly visible, irrespective of
system defaults.
For trunk, I propose we drop TLSv1 and TLSv1.1 protocols and simply adopt
the recommended cipher list illustrated below (!SSLv3) in the default
extra/httpd-ssl.conf source, following the SHOULD recommendations.
Comments?
---
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4
# Effective 2017, only TLSv1.2 ciphers should be in use.
# Older ciphers should be disallowed as soon as possible, however
# much older clients (such as IE6 SP2 on XP) may still be in use.
# Replace the SSLCipherSuite and SSLProxyCipherSuite directives
# above with these directives to restrict mod_ssl to TLSv1.2 ciphers
# as soon as practical.
# SSLCipherSuite HIGH:MEDIUM:!SSLv3
# SSLProxyCipherSuite HIGH:MEDIUM:!SSLv3
# As user agents such as web browsers are not configured for the user's
# own preference of either security or performance, and in every case
# this should be the prerogative of the web server administrator who must
# manage cpu load, enforce server's preferred cipher order.
SSLHonorCipherOrder on
# SSL Protocol support:
# List the protocol versions which clients are allowed to connect with.
# Disable SSLv2 and SSLv3 by default (cf. RFC 7525 3.1.1). TLSv1 (1.0)
# should be disabled as quickly as practical. By 2017, only the TLSv1.2
# protocol or later should remain in use.
SSLProtocol all -SSLv2 -SSLv3
SSLProxyProtocol all -SSLv2 -SSLv3
On Wed, May 6, 2015 at 4:32 AM, Steffen <in...@apachelounge.com> wrote:
> Maybe already known.
>
> The SSL/TLS best current practice RFC has been approved :
> https://www.rfc-editor.org/rfc/rfc7525.txt
>
> Steffen
>
>
>
SSL/TLS best current practice
Posted by Steffen <in...@apachelounge.com>.
Maybe already known.
The SSL/TLS best current practice RFC has been approved :
https://www.rfc-editor.org/rfc/rfc7525.txt
Steffen
Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to
2.4.13 / 2.2.30)
Posted by Yann Ylavic <yl...@gmail.com>.
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 <yl...@gmail.com> wrote:
> Possible backport patch attached.
>
> On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic <yl...@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.
Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to
2.4.13 / 2.2.30)
Posted by Yann Ylavic <yl...@gmail.com>.
Possible backport patch attached.
On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic <yl...@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.
Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to
2.4.13 / 2.2.30)
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic <yl...@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