SSL Cypher hardning

I the previouspost I described simple actions that you can take to harden your web server. It showed you headers that you can alter without too much interference on the functioning.

In this post, I go into more details on the TLS connection itself. The modern browser does quite a lot when a TSL connection is established.

There are multiple versions available to initiate a TLS/SSL connection. Not all of the supported versions are secure.

SSL vs TLS

The names SSL and TLS are two of the most misused words when talking about secure connections. An SSL connection is not secure! All web server demons do support both the SSL and TLS protocol.

SSL was originally developed by Netscape and first came onto the scene way back in 1995 with SSL 2.0 (1.0 was never released to the public). Version 2.0 was quickly replaced by SSL 3.0 in 1996 after a number of vulnerabilities were found. Note: Versions 2.0 and 3.0 are sometimes written as SSLv2 and SSLv3.

Currently, TLS is at version 1.2 and version 1.3 is in the draft stage.

SSLProtocol

A good thing about Apache is that the SSLv2 is not supported. But, SSLv3, TLSv1 and TLSv1.1 are.

In order to provide the best secure connection available we want to disable all 'not secure' protocols. this leads to the following Apache configuration directive:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

With this directive we disable the insecure versions of the protocol.

SSLCipherSuite

On this subject are a lot of discussions. To sum up a more or less consensus you should use:

sha256 certificates 4096-bit private key >2048 DH Pool size -

This leaves a lot for you to figure out and to be honest, I am no expert on this. What I found was that using:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH is the most advanced setting you can get. Problem is that you will block a lot of "older" browsers.

To keep secure and allow for most people to visit your site use:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

When using this setting be aware that the oldest compatible clients are: Firefox 27, Chrome 30, IE 11 on windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8

A more loose configuration will not block most of the browser that some of us are still forced to use at the worksite:

SSLProtocol all -SSLv3 SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Oldest compatible clients: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7

Other Cipher related settings

Above we decided on the TLS version to use and the Cypher suites we support. But the client and potential attacker can still play around with the cypher that is used on the connection. We want all browsers to use the strongest cypher available on the server. Normally the browser is responsible for selecting the suite, and probably will make a tradeoff between speed and security. With the directive SSLHonorCipherOrder we can force the server to be in control of order when the Cypher that is selected.

SSLHonorCipherOrder on

Compression Ratio Info-leak Made Easy (CRIME) is a security exploit against secret web cookies over connections using the HTTPS and SPDY protocols that also use data compression. When used to recover the content of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session, allowing the launching of further attacks.

CRIME is a client-side attack, but the server can protect the client by refusing to use the feature combinations which can be attacked. For CRIME, the weakness is Deflate compression. This alert is issued if the server accepts Deflate compression. Enabling compression causes security issues in most setups (the so called CRIME attack).

To harnas us against this attack use the following directive:

SSLCompression off

Each session has some form of nonce/unique is used to get a correct seed for the connection. Since this is a number and those tend to roll at a certain point it is possible to retrieve information about the keys used for the encryption. This can and will result in comprimised forward security. So disable this:

SSLSessionTickets off

References:

https://www.wolfssl.com/wolfSSL/Blog/Entries/2010/10/7 Differences between SSL and TLS Protocol_Versions.html http://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https http://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https https://cipherli.st/ http://httpd.apache.org/docs/current/mod/mod_ssl.html