SSL Cypher hardening

I the previous post 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

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.acunetix.com/vulnerabilities/web/crime-ssl-tls-attack ^[return]

SSL Cypher hardening

SSL vs TLS

SSLProtocol

SSLCipherSuite

Other Cipher related settings