April 19, 2014
In the last months more and more sysadmins started looking into their SSL configuration of their HTTPS websites. And one of the major sites that is used to rate/check the quality of the SSL configuration on a given HTTPS server is the Qualys SSL Labs SSL Server Test which can be reached via this link. If a sysadmin gets a not so good rating he search through the Internet and uses something like this settings (Apache 2.2 on Centos 6) to fix it:
SSLProtocol All -SSLv2 -SSLv3
Header add Strict-Transport-Security "max-age=15768000"
This leads at the time of writing (Quality SSL Labs changes the rating from time to time to following) to:
And now you are wondering why you get only a A- and what the problem with your configuration is. To make your journey shorter, the problem is most likely not the SSL configuration, it is the software you’re running. As you see on the screenshot the test reports that Forward Secrecy is not supported by all browsers and if you take a look at the details,
you’ll see that the problem is the Internet Explorer and that Forward Secrecy works for all other browsers.
(Perfect) Forward Secrecy
But what is (Perfect) Forward Secrecy in the first plage and why should you care. PFS ensures the integrity of a session key in the event that the private key of the server gets compromised. This is done by generating a separate session key for every new HTTPS session/connection.
Why should you care?
An attacker could record the SSL traffic for some time and later he got the private key and now without PFS he would be able to extract all the SSL traffic he was not able to look into before. Basically without PFS if a private key gets compromised you not only need to look the now and the future but also a the past and consider everything that was encrypted/signed by this key as compromised. With PFS you’re sure that an attacker is not able to extract data from before he got the private key. With the Heartbleed Bug in OpenSSL such an attack was possible or by hacking the server.
The cipher suites (the ones you choose with SSLCipherSuite in the Apache configuration) that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. The disadvantage of them is that they have a performance overhead, but the security is worth it and it is not that much overhead. With some elliptic curve variants the performance would be better.
A- and the workarounds
And how to the problem with the A- rating – I’ll quote Shadow Zhang who described it nicely in his post:
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 youre using DSA keys, but no one does; that’s a long story.) Apache does not support configurable DH parameters in any version, but there are patches you could use if you can install from source. 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.
Patching and compiling Apache is not the best idea, as you need to do it again for every security update. I see following options:
- Use a distribution version which supports Apache 2.4
- Use Nginx as reverse proxy in front of the Apache because it fully supports ECDHE.
- Change to a web server that is shipped with your distribution and that does support ECDHE.
I hope this post helped and saved you some time looking through the internet for a solution.