I tried to follow the instructions given in this article by Ivan Ristic, but somehow it seems not to be working, or the test at https://www.ssllabs.com/ssltest/ might be broken… 🙁
Unfortunately I can’t seem to comment on Ivan’s article (I even registered just to reply), so I created this blog post, hoping that my trackback will work…
This is what I have in Apache:
SSLHonorCipherOrder On SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
According to the output of openssl ciphers this should enable the following cipher suites (filtered by only those that contain ECDHE):
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 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 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 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 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-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
As far as I can tell this should include the below cipher suites which supposedly enable forward secrecy:
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Unfortunately the above SSL test shows the following when running towards my Apache:
Forward Secrecy No
Does anyone know what that means? Is the test just broken, or am I misunderstanding anything?
20 replies on “Enabling Forward Secrecy in Apache”
Hi, as you noticed, openssl’s cipher-suite tokens make it hard to understand what you are actually configuring. Also the values change, from version to version. So I recommend just being explicit and list exactly what you want, in the order you want.
Also all the “ECDHE-ECDSA” suites actually requires a new, different (i.e. expensive) certificate that you don’t have, so they are all ignored.
Ok now your problem.
You are correct that “ECDHE-RSA-AES128-SHA256” provides forward secrecy, however as of 07/2013 most browsers don’t support it as it is for TLS1.2 only. Next on your list is ECDHE-RSA-RC4-SHA. That is supported by most clients, but not quite all, so you need another. The next one that would support forward secrecy by current browsers is “ECDH-RSA-AES128-SHA” but that’s near the end of list due to the magic of OpenSSL. Most client will use another cipher before getting to that.
Here’s the magic formula:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:RC4-SHA:AES128-SHA:AES256-SHA:DES-CBC3-SHA
If that get’s mangled here’s the order
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-RC4-SHA
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-DES-CBC3-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA256
RC4-SHA
AES128-SHA
AES256-SHA
DES-CBC3-SHA
This will:
* provide forward secrecy to most reasonably modern clients
* protected against the BEAST attack
* will provide improved security as more clients enable TLS 1.2
* will be provide some security for people stuck on WindowsXP (which is still a large percentage of traffic)
if you want to be a maniac, you can flip the order of the ciphers so 256 come first, but that’s likely to not buy you much.
Assuming your OpenSSL is up to date, I think you’ll be pleased by the results next time you check
enjoy!
nickg
Hi Nick. Thanks for your reply and valuable input.
Actually I use a free CAcert SSL certificate — not sure whether they can issue certificates for keys using the “ECDHE-ECDSA” suites…
I configured my server to use the crypto suites you suggested (flipping the order of the ciphers to have 256 first :-)), but still I don’t have forward secrecy as per SSLTest’s Protocol Details:
Any idea why this is?
My OpenSSL version is the current one from Debian stable,
1.0.1e-2.> as of 07/2013 most browsers don’t support it as it is for TLS1.2 only
That is misleading and incorrect. ALL current browsers support TLS 1.2. Firefox, Opera, Crome, Safari, and even IE. And I mean on PCs (Linux, OS X, Win) and mobile phones (Android, iOS).
[Of course if you use a outdated browser and/or OS, it won’t work. But then you’ll have much bigger problems anyway… like Russian botnet operators selling your compromised box to child porn and spam distributors. As least until the cops come for you and the press calls you a pedo.]
The only exception is Firefox, which still has it disabled by default for no reason in the current version, but enabled in the development ones. I enabled it, and it works like a charm. So it really is disabled for no reason.
Here’s how to enable it in Firefox 2.21 (aka 25.0 in the “rapid release” insanity bubble):
• Go to
about:config.• Search for
security.tls.version.max• Double-click on the value and change it to
3. (Yes, 3! 1 = 1.0, 2 = 1.1, 3 = 1.2. Yes, that shouldn’t be that way.)That is very valuable advice, thanks on behalf of all my readers.
Even if openssl can provide ECDHE the apache 2.2 in debian stable does not support this mechanism. You need apache 2.4 to fully support forward secrecy.
A workaround could be the usage of nginx as a reverse proxy because it fully supports ECDHE.
@Das_Schaf Thanks for your reply. That would explain why I simply couldn’t get it working, regardless how hard I tried. 😉
Thanks for suggesting to use NGiNX as a reverse proxy, but that is not an option for me — I’m not running a commercial web server, just doing it as a hobby, and I want to keep my setup as simple as possible (for work we use reverse proxies almost everywhere…)
Or upgrade to Apache 2.4 like a normal person.
It doesn’t differ in its dependencies, so there’s zero hassle.
The only required configuration changes are trivial and done with at most half a dozen simple regexp replaces. (I used 3.)
And the init script warns you about them (with file name and line) and doesn’t touch the running processes until everythnig is fine.
There’s really zero reason to stay on 2.2., except for being a conservative pussy who’s too afraid of the world for his own good.
Hehehe. 🙂
I think you may be too harsh here. Some people simply can’t upgrade to 2.4 since they need to stick to Debian stable — and that distro still is on 2.2. 🙁
I’m looking into enabling ECDHE and DHE myself and as far as I understand it, OpenSSL needs DH parameters and an elliptic curve to be able to offer / use DHE and ECDHE.
In lighttpd you can just add a file with DH parameters (generated with ‘openssl dhparam’) and the name of a named elliptic curve (from ‘openssl ecparam -list_curves’) to your config and you’re good to go. (http://redmine.lighttpd.net/projects/1/wiki/Docs_SSL#Diffie-Hellman-and-Elliptic-Curve-Diffie-Hellman-parameters)
I haven’t figured out how to do this with Apache’s mod_ssl or with Pound, though. The only thing I’ve found so far, is that with some programmes you can just add PEM-encoded DH parameters to your PEM-encoded keyfile. (This works with Pound and our qmail-ssl-patch.) I’m still trying to figure out, how to force-feed EC parameters to these programmes.
Please look at what “Das_Schaf” wrote — eventually you’re also using Apache 2.2?
You can get PFS with Apache 2.2 if you use the DHE variants of the ciphers instead of the ECDHE. They are just slower to negotiate.
I have implemented cipher suite in apache2.2:
TLSv1.2:TLSv1:-MD5:-aNULL:-MED:-LOW:-EXP:-NULL
Stick in RC4 closer to the front if you worry about BEAST.
Thanks for suggesting this. Unfortunately I cannot get PFS using the DHE variants. Just tried the following, and according to Qualys’ SSL Labs test I don’t have forward secrecy:
SSLCipherSuite DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-RC4-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:RC4-SHA:AES256-SHA:AES128-SHA:DES-CBC3-SHAAccording to different other sources it is not possible to have PFS on current Debian servers using Apache 2.2, e.g. here (German only, sorry). 🙁
Have you actually checked that your suggestion gives you PFS, e. g. by using Qualys’ test tool?
Actually, the non-elliptic-curve variants of the DHE are defective by design, as the NSA deliberately introduced flaws into the algorithm, making that whole thing completely pointless.
For your own good, please use ECDSA… or something completely different. I don’t think you like being lulled into a false sense of security, are you? Not for some 30-minute convenience. It’s not worth it.
Because that’s how long the migration to Apache 2.4 actually takes. Tops. Including the trivial config changes. 🙂
The Qualys SSL Test may be broken, it says google.com and gmail.com do not have PFS either, but Google says they do.
Hi,
I know this thread had been going on for some time now, but I’ve just come across it and I thought it would be best to respond, late as I am.
I published another post about Forward Secrecy in the meantime (August), and that one goes into detail about how to configure Apache, and emphasizes that Forward Secrecy only works in Apache 2.4.x.:
http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
With Apache 2.2.x you have only DHE suites to work with, but they are not enough. Internet Explorer (in all versions) does not support the required DHE suites to achieve Forward Secrecy. (Unless you’re using DSA keys, but no one does; that’s a long story.)
The SSL Labs is not broken, it’s just thorough. In order to declare that a site supports Forward Secrecy, we require that the support is enabled across all browsers we use in our Handshake Simulator. If you take a look at Google (mentioned in this thread), they support only ECHDE suites, but no DHE suites. As a result, there is no Forward Secrecy with some older browsers. So that’s a reason they got a “no”.
Last week I deployed an update that adds some granularity to the Forward Secrecy test. The possible outcomes are now: no, modern browsers (ECDHE suites supported), and robust (ECDHE and DHE suites supported).
Apache does not support configurable DH parameters in any version, but there are patches you could use if you can install from source. I wrote about that here:
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html
They’ve just recently made some changes to the trunk, and now there is a patch against 2.4.x that auto-configures DH strength to match that of the private key:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49559
Hi Ivan.
Thanks for your elaborate response.
I’m sure I also speak for my readers thanking you for shedding some more light on this important, but complex and complicated matter.
Best regards,
Ralf
Still wrong. ANY form of PFS is completely useless, if both sides allow downgrading to non-PFS ciphers. Because then you can just force it with a MITM attack.
And I, for example, simply do not offer ANY non-PFS ciphers. If a user still uses a browser that can’t do that, then he can go fuck himself, and take his FAIL somewhere else, because he’s a danger to others aswell as himself.
(I have non-HTTPS disabled in Apache and blocked anything not encrypted with the best ciphers in my firewall.)
You have a good point here. 😉
If you’re really paranoid (and there are good reasons to be paranoid) and want maximum security then your suggestions make a lot of sense.
You may be right, unless you do have “real” customers. In B2B roughly 20% still use IE6, adding another 30% for IE<10.
I know you’re right w/ B2B — I work for a huge company, and we still use an ancient version of IE for compatibility reasons to legacy applications… :-/
But for me personally it doesn’t matter, since I only serve private users who can upgrade at will…