Since my last article, there has been a lot of movement : new vulnerabilities have appeared, but a good setup might have protected you (especially if you decided to drop SSLv3 support).

Let’s begin on an excellent news from the Apache project : version 2.2.30 will support strong DH exponents as detailed in this commit.

TL;DR: updated cipher suites are at the end of the document.

SSLv3 : the weak link

Since my last post, the POODLE attack was disclosed, proving SSLv3 to be weak. For a reminder, in 2013, I did an implicit recommendation to disable SSLv3, which was already more than obsolete at that time. The caveat to this is that obsolete OS like MS Windows XP are not natively compatible with TLS 1.0.

If you’re still using Windows XP, and if you can’t migrate from it, please follow the following guide from certiport to enable TLS 1.0. Please use this opportunity to disable SSLv2 and SSLv3: as Windows XP is not supported anymore, the internal libraries won’t benefit from the TLS_FALLBACK_SCSV flag to detect a downgrade attack.

RC4: partially broken, pruned by IETF

According to a 2013 publication which deals with the state of RC4 in TLS, this cipher has been partially broken in some conditions. Therefore, it should be considered as weak, and it MUST (I strongly emphasize on this) be rolled out as soon as possible from production.

At the beginning of this year, the IETF has written RFC 7465 to prohibit the use of RC4 cipher suites. This document is, at the date of publication, a proposed standard.

ChaCha20-Poly1305: a promising newcomer

The obsolescence of RC4 has a significant impact for high traffic servers and low-resources devices (phones, embedded systems…) Indeed, AES performances are lower to RC4’s on hardware that don’t implement specific instruction sets. In regard of these issues, Google has implemented a new stream cipher that runs efficiently without any need of hardware implementation.

Beside Google’s work on this cipher, current adoption is still marginal, because the cipher specification process on the IETF side has been on hiatus for a while. However, it’s now published, and implementation in IPSec/IKE is to be published soon. No work has been performed for TLS yet, but you can track the evolution on the IETF datatracker here.

Up to now, this cipher is implemented in Android, and in Windows build of Google Chrome, but there is no upstream implementation in the most popular TLS libraries because the developpers are waiting for the cipher suite ID bytes to be standardized.

However we can think Chacha20-Poly1305 will gain traction once its specification is standardized for TLS.

3DES: Necessary evil for legacy support

Now that RC4 has been proven insecure, there is only one « safe » (112 bit of effective key size) cipher suite on Windows XP: TLS_RSA_WITH_3DES_EDE_CBC_SHA. There is another suite that uses 3DES, but it requires use of DSA keys, which size are effectively limited to 1024 bits on Legacy OS.

I insist that this cipher suite is to be included only for legacy support, put it at the end of your cipher suite, and you should remove it as soon as possible.

TLS 1.3 : what to expect so far

The IETF is currently working on TLS version 1.3 which will essentially focus on cleaning the crufty legacy features that one shouldn’t use today (compression, non-AEAD ciphers, DHE key exchange…), and improving the protocol performances and strength.
 

Recent attacks messing with both the client and server sides.

The support for « export » cryptography on the client side has been leveraged downgrade the security of connections. FREAK targets old cipher suites (e.g. DES with 56 bit keys), and Logjam targets Diffie-Hellmann ephemeral key exchange, by using weak key length (512 bits moduli). The best way to mitigate these attacks is to upgrade your browser to the last version.

The updated TLS cipher suites

A significant change has been performed on the suggested cipher suites: DHE suites are put after all ECDHE because of the risks induced by Logjam attacks, and because ECDHE key exchange is significantly faster than DHE key exchange. AEAD ciphers (with built-in authentication) and TLS 1.2 ciphers are put first.

This profile is built with performance in mind. It features 128 bits ciphers first.

SSLProtocol all -SSLv3 -SSLv2
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:CAMELLIA128-SHA:AES128-SHA:CAMELLIA256-SHA:AES256-SHA

The second profile is built with maximum security. 

SSLProtocol all -SSLv3 -SSLv2
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

The third profile is built for legacy support, based on the performance profile.

SSLProtocol all -SSLv3 -SSLv2
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:CAMELLIA128-SHA:AES128-SHA:CAMELLIA256-SHA:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Bonus: Enabling HSTS

HTTP Strict Transport Security (HSTS) is a security mechanism which is to HTTPS websites against downgrade-to-HTTP attacks. Compatible browsers will remember websites that show the appropriate headers, and redirect any http request to https.

Enabling HSTS is a good practice to apply when your TLS setup is stable and mature.

To do so, you must enable mod_headers and add the following line on your TLS-Enabled virtual host:

Header always set Strict-Transport-Security "max-age=15768000"

If all your subdomains are properly set up, you can add includeSubDomain at the end of the value of the header, as follow.

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"
Publicité