Updated SSL/TLS Deployment Best Practices Deprecate RC4

Ivan Ristic

Last updated on: October 21, 2021

We are releasing an update to our SSL/TLS Deployment Best Practices document, which is our comprehensive guide to running secure servers. This is our third update since the first release in February 2012; our main goal is to keep the document up to date with the threats as they’re evolving.

Since the beginning of the year we saw three major developments:

  • In March, a group of security researchers demonstrated that RC4 is seriously broken. Although the attack is not yet very practical, we are now recommending that this cipher is phased out. In the previous versions of the guide we had recommended using RC4 to mitigate the BEAST attack server-side. Clearly, this is no longer possible. Although we think that the BEAST attack can still be a threat in some environments, disabling RC4 globally will take a long time and we believe that we need to start that process straight away.
  • Last year, we learned about the CRIME attack, which uses information leakage stemming from compression before encryption. This year, CRIME evolved into TIME and BREACH, two attacks that go beyond attacking TLS compression (which is easy to disable without consequences) to attack the ubiquitous HTTP compression. Because they fall outside SSL/TLS, TIME and BREACH can only be addressed by making changes to application source code. For most, this approach will require a lot of work.
  • Finally, this year we also learned some details about widespread surveillance programs worldwide. In particular, it came to light that server private key compromise is a commonly used approach to breaking secure communication. For this reason, we now recommend that all secure servers support Forward Secrecy. With this feature enabled, each connection uses separate encryption keys, which means that the encrypted data remains safe if the server private key is compromised.

In addition to addressing these major threat changes, we took the opportunity to include several incremental updates, for example to recommend that you retire 1024-bit keys, SSL 3, and 3DES. We also included a discussion about new technologies, such as ECDSA keys.

Download SSL/TLS Deployment Best Practices v1.3 from the SSL Labs web site.

Show Comments (4)

Leave a Reply to Thomas Martin Cancel reply

Your email address will not be published. Required fields are marked *

  1. Great work Ivan, like always.

    I’m trying to follow your recommandations carefully, I read this document and a previous article (ref: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy).

    So I disabled SSLv3 and RC4:

    ssl_prefer_server_ciphers on;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_ciphers EECDH-ECDSA-AESGCM:EECDH-aRSA-AESGCM:EECDH-ECDSA-SHA384:EECDH-ECDSA-SHA256:EECDH-aRSA-SHA384:EECDH-aRSA-SHA256:EECDH-aRSA-RC4:EECDH:EDH-aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;

    With this configuration FS works just well but some clients can’t used SSL:

    * Firefox 21 / Fedora 19
    * IE 6 / XP
    * IE 8 / XP
    * Java 6u45
    * OpenSSL 0.9.8y
    * Opera 12.15 / Win 7

    I’m worried about Java 6u45 and OpenSSL 0.9.8y.

    Did I missed something or do you have the same results?

    I can’t wait for your book to be released!

    Thanks.