apache2.2 SSL has no forward-secrecy: need ECDHE keys

Thanks for your assistance.

Can I ask why you think this is merely a wishlist item?

If I've understood the import of this correctly, then the privacy of every visitor to every website served by Apache on every version(*) of Ubuntu is at risk. I don't think that forward-secrecy in SSL is an optional extra; I think it's a requirement. Also, in my view, server administrators who deploy https are making an implicit promise to their site's visitors - and this is a promise which they cannot honour.

(*)even Saucy doesn't have 2.4 packages yet, though 2.4 is in Debian, Mageia, and Fedora.

Just to answer this, the upgrade has hit Saucy, and I have tested it successfully. I'll mark it as fix-committed. Thanks for your time.

Don't you think it would be better to backport this for Apache 2.2?
What about all the Ubuntu 12.04 LTS versions which will be running for some more years?

+1 for Chris question. Any plans for an Apache 2.2 back-port?

An Apache 2.2 back-port would be great. what are the plans for this?

+1 on the backport. I'm a co-founder of a non-profit. Our websites have to default to SSL to protect the privacy of our clients. Since this is a production webserver, we can only use Ubuntu 12.04 LTS as that's what our IaaS vendor offers us for Ubuntu/Debian distros. The lack of forward-secrecy is a risk exposure to us and would like see it addressed.

Yeah I have to add my +1 to this too, as I feel waiting for Ubuntu 14.04 LTS is too long!

Since this is fixed in Saucy, I'm marking this bug as Fix Released. If you want PFS in an official Ubuntu release, use Ubuntu 13.10.

I understand that some of you want this feature backported to 12.04. That's fine, but this is a considerable amount of work and I don't think it falls under the Ubuntu "LTS" remit. If somebody wants to backport Apache 2.4 and make it available in 12.04, please do so - see https://wiki.ubuntu.com/UbuntuBackports for the process. Or alternatively, publish and maintain a third party PPA and announce it here.

Backports and PPAs are the acceptable options here. We do not backport features to LTS releases. That's why they're LTS - because you expect them to be stable and not introduce unnecessary regressions. You may want PFS added, but others don't want their production systems running on LTS messed with. So we generally do not backport features, and I don't think PFS warrants an exception. See https://wiki.ubuntu.com/StableReleaseUpdates for the policy. Your route is simple: if you want a new feature, use a newer release, or sponsor the backport work yourselves and use a third party maintained backport or PPA.

I thought this request felt under the below wording in https://wiki.ubuntu.com/StableReleaseUpdates :

<quote>
Stable release updates will, in general, only be issued in order to fix high-impact bugs. Examples of such bugs include:

Bugs which may, under realistic circumstances, directly cause a security vulnerability. These are done by the security team and are documented at SecurityTeam/UpdateProcedures.
...
</quote>
I believe this threat is very realistic ( http://blog.ivanristic.com/2013/06/ssl-labs-deploying-forward-secrecy.html ). I guess the metrics to determine what warrants an exception are up to you for sure but as far as I can tell the privacy cost of this vulnerability justifies the upgrade for apache servers *only* or the usage of a PPA like https://launchpad.net/~derek-morton/+archive/apache-2.4 if you decide to trust it or simply building apache 2.4 from scratch. If the server is not running apache clearly there is nothing to be worry about.

Thanks for the statement because at least the wait is over.

Best,
- Nestor

This bug is for Apache 2.2 not for Apache 2.4 so don't mark as fix released when thats not the case...

This has been fixed already in Debian 7.6 and there is a debdiff for it so there should not be a considerable amount of work to apply it right now.

Ubuntu 12.04 will be supported until 2017 thats 3 more years, this qualify as SRU as the regression potential is near to zero, since it just adds support for more ciphers to Apache, if for some reason anyone don't want to use the EC cipher suites just add !ECDH to the list of cipher suites.

Thank you for linking the Debian bug.

> This bug is for Apache 2.2 not for Apache 2.4 so don't mark as fix released when thats not the case...

The status is defined to reflect the status in the development release, where it is fixed. I'll add a Precise task for you though, to track status for 12.04 specifically.

> This has been fixed already in Debian 7.6 and there is a debdiff for it so there should not be a considerable amount of work to apply it right now.

Agreed. That Debian has chosen to do this suggests that it may be a good idea for Ubuntu also, and that there is a way to minimise regression.

> ...as the regression potential is near to zero

Message https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733564#37 suggests that this is not true, and that we need to also patch openssl to avoid regressing Mac clients. Please can you expand on this?

If someone can post a debdiff and post an accurate regression potential analysis, then I think it's fine to ask the SRU team to consider this case.

I would still want someone to drive this please; both in preparing the patches for Ubuntu, and also in thoroughly testing for regressions during the SRU process.

I would note though that 14.04 is out now, so an LTS path is also already available to users.

hi,

i included the patch from debian to ubuntu. Added an debdiff.

about the openssl/mac os x problem:

if i follow the ciphers from https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

ciphers with ECDHE-ECDSA-* are not enabled, so this should not be a problem.
for details see http://wiki.openssl.org/index.php/SSL_OP_SAFARI_ECDHE_ECDSA_BUG

my patched apache is now running without any problem more than a week.

for a quick & dirty solution you can replace /usr/lib/apache2/modules/mod_ssl.so (x86_64)

FYI, ECDHE-ECDSA-* cipher suites are only enabled when using ECDSA SSL certificates (with RSA being the most common).

i created a ppa: https://launchpad.net/~jonathan00/+archive/ubuntu/apache2/

@Haw: Thanks for the info

With the recently released logjam attack, can we please revisit and increase the priority for, backporting ECDHE support to apache2.2?

https://weakdh.org/
http://openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/

I'll work on releasing this for precise next week.

This is a patch I created, by backporting 2.4 commits for DH keys to 2.2, to solve the DH keys too small issues on certs.

Adding here in case it helps anyone.

I did not want to wait until this is fixed for apache 2.22 in Ubuntu 12.04

So I took mod_ssl from apache 2.2.29 which supports ECDH.
Additional I removed the 512 and 1024 bit DH parameters from ssl_engine_dh.c and replaced them with 2048 and 3072 bit.
Two DH keys are not needed because libssl in 12.04 never asks for more than 1024 bit so always 3072 are returned. But I realised this afterwards....

You can download my modified mod_ssl from http://download.ict-pros.co.tz/mod_ssl-apache2.22.tar.bz2
Short instructions:
apt-get source apache2
apt-get build-dep apache2
Replace modules/ssl with the modified version.
Run within modules/ssl perl ./ssl_engine_dh.c to generate your own DH parameters.
Build the package. After updates mod_ssl.so will be overwritten so you have to copy your compiled version from debian/apache2.2-bin/usr/lib/apache2/modules/ to /usr/lib/apache2/modules/ and restarting apache.

Andreas

There is a test package for precise available here:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages

Once it has gone through testing, it will be published as an update.

https://bz.apache.org/bugzilla/show_bug.cgi?id=49559#c20

This bug was fixed in the package apache2 - 2.2.22-1ubuntu1.9

---------------
apache2 (2.2.22-1ubuntu1.9) precise-security; urgency=medium

  * SECURITY IMPROVEMENT: add support for ECC keys and ECDH ciphers
    (LP: #1197884)
    - debian/patches/ecc_support.patch: add support to
      modules/ssl/mod_ssl.c, modules/ssl/ssl_engine_init.c,
      modules/ssl/ssl_engine_kernel.c, modules/ssl/ssl_private.h,
      modules/ssl/ssl_toolkit_compat.h, modules/ssl/ssl_util.c,
  * SECURITY IMPROVEMENT: add TLSv1.x options to SSLProtocol (LP: #1400473)
    - debian/patches/tls_options.patch: allow specifying later TLSv1.x
      options in modules/ssl/mod_ssl.c, modules/ssl/ssl_engine_config.c,
      modules/ssl/ssl_engine_init.c, modules/ssl/ssl_engine_kernel.c,
      modules/ssl/ssl_private.h.
  * SECURITY IMPROVEMENT: improve ephemeral key handling, including
    allowing DH parameters to be loaded from SSLCertificateFile and
    disabling EXPORT ciphers.
    - debian/patches/ephemeral_key_handling.patch: numerous improvements to
      modules/ssl/mod_ssl.c, modules/ssl/ssl_engine_config.c,
      modules/ssl/ssl_engine_dh.c, modules/ssl/ssl_engine_init.c,
      modules/ssl/ssl_engine_kernel.c, modules/ssl/ssl_private.h,
      modules/ssl/ssl_util_ssl.c, modules/ssl/ssl_util_ssl.h.

 -- Marc Deslauriers <email address hidden> Thu, 28 May 2015 12:26:50 -0400