Mozilla created an extensive page [7] concerning the best current choice of SSL/TLS cipher suites, primarily for web servers. Compass Security agrees broadly with the article, but recommends some additional restrictions in order to provide the most resistance against active and passive attacks versus TLS secured connections:

  • Use 3DES cipher instead of RC4
  • Disable SSLv3 support

Compass Security recommends against using RC4, and favors 3DES for a transitional period. 3DES only provides 112 bit keys (and may therefore be more prone to brute force attacks on the key), but is otherwise regarded as not (yet) broken. RC4, on the other hand, is considered not secure anymore:

  • A “nearly practical” attack exists, as the first bytes of the stream cipher are biased (not perfectly random)[4]
  • Microsoft recommends to disable it, and warns developers to not use it anymore [1]
  • The NSA is suspected to be able to decrypt it in real-time [2][3]
  • RC4 was primarily used to thwart BEAST and Lucky13 attacks. But BEAST is fixed on current browsers. Exploiting Lucky13 is currently not practically feasible [6]

For additional security, it is possible to remove SSLv3 support altogether, as it contains several weaknesses:

  • Weaker key derivation process than TLS
  • Cannot be validated under FIPS 140-2
  • There have been various attacks on SSLv3 implementations
  • Vulnerable to certain protocol downgrade attacks

TLSv1.0, which was released in 1999, contains several additional security features in comparison to SSLv3. For example, it uses both SHA-1 and MD5 at the same time, making it less vulnerable if one of these hash functions becomes insecure.

All browsers, except IE6 on Windows XP (in its default configuration) support at least TLSv1.0. The default IE8 browser on an up-to-date Windows XP, happily connects to TLS-only web servers. Nevertheless, other software may not be compatible with such an restricted configuration yet.

Furthermore it is recommended to turn off TLS compression. This will fix the CRIME attack on TLS connections, even if vulnerable OpenSSL implementation on the server is being used, while an obsolete browsers which do not have this issue fixed is connected. If the server uses current OpenSSL library, and/or the client has the CRIME fix implemented, this attack is not feasiable anyway. Turning off TLS compression will not mitigate the BREACH attack, as it uses the compression feature of HTTP, not TLS. See [12] for further information about this issue.

This concludes the discussion about most of the currently known SSL/TLS attacks, and their mitigation.

Update April 2015: Web Server configuration generator

An up to date and detailed Apache SSL/TLS configuration generator can be found here: Mozilla SSL Configuration Generator. Mozilla changed their opinion on RC4, and also switched to 3DES for backwards compatibility.

Apache Configuration

The following chapter provides an Apache configuration example, which incorporates the discussion above. It is based on  https://wiki.mozilla.org/Security/Server_Side_TLS

The implemented cipher prioritization logic is as follows:

  1. Most secure TLS 1.2 ciphers first: AES-GCM
  2. AES with PFS: ECDHE (Elliptic Curves)
  3. AES with PFS: DHE (Traditional RSA)
  4. AES128
  5. AES256
  6. 3DES

The cipher prioritization list:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK

Virtual host SSL configuration:

<VirtualHost *:443>
    ...
    SSLProtocol             All -SSLv2 –SSLv3
    SSLCipherSuite          <recommended ciphersuite from above>
    SSLHonorCipherOrder     on
    SSLCompression          off # default off, except in 2.4.3 and 2.2.24 to 2.2.25
    SSLInsecureRenegotiation off # default
    ...
</VirtualHost>

This TLS- and AES/3DES-only configuration was successfully tested with current versions of IE8, Chrome and Firefox on Windows XP.

Windows IIS

Example configuration settings for Windows. This should act as a basic configuration skeleton. Before deployment, the configuration needs to be actively tested in an production environment. The cipher list has been extracted on a Windows 7, but is identical to that of a Windows 2012 Server.

Disabling SSLv2 and SSLv3:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server] 
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server] 
"DisabledByDefault"=dword:00000001

Cipher list:

  1. ECDHE ECDSA AES-GCM SHA2
  2. ECDHE ECDSA AES-CBC SHA2
  3. ECDHE RSA AES-CBC SHA2
  4. ECDHE RSA AES-CBC SHA
  5. ECDHE ECDSA AES-CBC SHA
  6. DHE DSS AES-CBC SHA2
  7. DHE DSS AES-CBC SHA
  8. DHE DSS 3DES SHA
  9. RSA AES SHA2
  10. RSA AES
  11. RSA 3DES
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA

Configure Schannel according to the recommendations above and these pages:

Update February 2015: TLS1.0 discussion

With the discovery of the POODLE attack, it is now widely recommended to disable SSLv3 support. But it is important to realize that neither TLS 1.0 or TLS 1.1 are considered secure. Especially TLS1.0 contains only small improvements over SSLv3.

Luckily, TLS 1.1 does not have any publicly known protocol problems. Nevertheless, TLS 1.2 implements stronger and more trustworthy algorithms. For example TLS 1.1 uses SHA1/MD5 in the pseudorandom function, both of them are considered broken. TLS 1.2 uses SHA2. It also supports the new GCM ciphers, which are more resistant against certain attacks than CBC ciphers.

Sadly, the support for TLS1.1 for Internet Explorer in its default configuration is only available for IE11 on Windows 7 and higher. Schannel supports TLS1.1 from Windows 7 onwards, which includes IE7/8/9, but is not active “out of the box”. Therefore it is not possible for Compass to recommend TLS1.1/1.2-only public facing websites, even if security considerations dictate so. Nevertheless for web interfaces where the supported user-base is known, it should be evaluated to disable TLS1.0, and even TLS1.1. For example a public facing firewall configuration web interface, where all users of it are known to have Chrome installed.

Further Recommendations

This renewal in favor of more secure SSL ciphers can be a good opportunity to kick-off further clarifications and investigations about SSL related topics in your company, e.g.:

  • Is all your web infrastructure (proxies, WAFs, web servers, …) ready to support TLSv1.1 and TLSv1.2?
  • Are the clients you manage use an adequate configuration for setting up SSL communication (e.g. Prioritizing Schannel Cipher Suites for Windows clients)
  • Does your SSL certificate use at least a 2048 bit private key?
  • Do your CA SSL certificates use at least 4096 bit private keys?
  • Does your internal PKI enforce best practices and is moving to SHA2 and ECC? [10][11]
  • Are you using the most current version of the webserver?
  • Are you using the most current version of OpenSSL?

References

  1. Microsoft recommends disabling RC4
  2. Article about suspicious that NSA is able to decrypt RC4
  3. Article about suspicious that NSA is able to decrypt RC4, german
  4. Bruce Schneier about attack on RC4 from spring 2013
  5. Discussion “RC4 is kind of broken in TLS”
  6. Qualys Discussion about retiring RC4
  7. Mozilla Article about SSL ciphers
  8. Qualys SSL Test
  9. Web Browser Support Matrix
  10. MS SHA1 deprecation policy
  11. Windows Root Certificate Program – Technical Requirements version 2.0
  12. Nginx SSL Module
  13. Qualys – Defending against the BREACH Attack

Thanks to Alexandre Herzog for research, review and discussions concerning this matter.