There are many great questions that ask what is the best certificate to use for a website; but once the certificate is purchased, there is also the possibility to choose or edit the Cipher list.

Although each vendor may call this setting something slightly different, my understanding is that the Cipher List is used to negotiate encryption protocols between the client and the server.

  1. What are the basics of choosing a Cipher list for my website? If the defaults need to be altered Where should "beginners" go to get reliable advice?

  2. Have any of the traditional recommendations changed as of September 2011's BEAST or 2012's CRIME attack?

  3. Does anyone maintain a list of ciphers supported by OS/Vendor/and version? Is it correct to say that something like this would be useful?

  4. Are some certificates incompatible or not preferred with certain ciphers?

  5. Where can I learn more? Specifically, how can I get a cursory ability to compare Ciphers without having to retake some post-secondary math classes?

6 Answers 6


In SSL/TLS, the cipher suite selects a set of algorithms, for several tasks: key agreement, symmetric encryption, integrity check.

The certificate type impacts the choice of the key agreement. Two parameters must be taken into account: the key type and the key usage:

  • With a RSA key you can nominally use the "RSA" and "DHE_RSA" cipher suite. But if the server certificate has a Key Usage extension which does not include the "keyEncipherment" flag, then you are nominally limited to "DHE_RSA".
  • With a DSA key you can use only a "DHE_DSS" cipher suite.
  • With a Diffie-Hellman key, you can use only one of "DH_RSA" or "DH_DSS", depending on the issuing certificate authority key type.

Most SSL server certificates have a RSA key which is not restricted through a Key Usage extension, so you can use both "RSA" and "DHE_RSA" key types.

"DHE" stands for "Diffie-Hellman Ephemeral". This allows Perfect Forward Secrecy. PFS means that if an attacker steals the server private key (the one which is stored in a file, hence plausibly vulnerable to ulterior theft), he will still not be able to decrypt past recorded transactions. This is a desirable property, especially when you want your system to look good during an audit.

For the integrity check, you should not use MD5, and, if possible, avoid SHA-1 as well. None of the currently known weaknesses of MD5 and SHA-1 impacts the security of TLS (except possibly when used within a certificate, but that's chosen by the CA, not you). Nevertheless, using MD5 (or, to a lesser extent, SHA-1) is bad for public relations. MD5 is "broken". If you use MD5, you may have to justify yourself. Nobody would question the choice of SHA-256. The general consensus is that SHA-1 is "tolerable" for legacy reasons.

For symmetric encryption, you have the choice between (mostly) RC4, 3DES and AES (for the latter, the 256-bit version is overkill; AES-128 is already fine). The following points can be made:

  • RC4 and 3DES will be supported everywhere. The oldest clients may not support AES (e.g. Internet Explorer 6.0 does not appear to be able to negotiate AES-based cipher suites).

  • There are known weaknesses in RC4. None is fatal right away. Situation is somewhat similar to that of SHA-1: academically "broken", but not a problem right now. This still is a good reason not to use RC4 if it can be avoided.

  • 3DES is a 64-bit block cipher. This implies some (academic) weaknesses when you encrypt more than a few gigabytes in a single session.

  • 3DES can be heavy on your CPU. On a 2.7 GHz Intel i7, OpenSSL achieves 180 MB/s encryption speed with AES-128 (it could do much better if it used the AES-NI instructions) but only 25 MB/s with 3DES. 25 MB/s is still good (that's 2.5x what a 100 Mbits/s link can handle, and using a single core) but might not be negligible, depending on your situation.

  • The BEAST attack is an old academic weaknesses which has recently been demonstrated to be applicable in practice. It requires that the attacker spies on the link and runs hostile code on the client (and that code must communicate with the external spying system); the BEAST authors have managed to run it when the hostile internal code uses Java or Javascript. The generic solution is to switch to TLS 1.1 or 1.2, which are immune. Also, this concerns only block ciphers in CBC mode; RC4 is immune.

  • In a SSL/TLS handshake, the client announces his supported cipher suites (preferred suites come first), then the server chooses the suite which will be used. It is traditional that the server honours the client preferences -- i.e. chooses the first suite in the list sent by the client that the server can handle. But a server could enforce its own order of preferences.

  • DHE implies somewhat higher CPU consumption on the server (but it will not make a noticeable difference unless you establish several hundreds new SSL sessions per second).

  • There is no DHE cipher suite which uses RC4.

Summary: this leads me to the following preferred list of cipher suites. If the BEAST attack may apply to you (i.e. the client is a Web browser), use this:

  • If the session uses SSL-3.0 or TLS-1.0, try to use TLS_RSA_WITH_RC4_128_SHA.
  • If the client supports TLS 1.1+, or if it does not support TLS_RSA_WITH_RC4_128_SHA, or if you consider PFS to be more important to you than BEAST-like active attacks (e.g. you are most concerned about long-term confidentiality, not immediate breaches), then use TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (fallback to TLS_DHE_RSA_WITH_AES_128_CBC_SHA if the client does not support SHA-256).
  • If DHE cipher suites are not supported by the client, use the corresponding non-DHE suite.
  • Generic fallback is TLS_RSA_WITH_3DES_EDE_CBC_SHA which should work everywhere.

Note that the choices above assume that you can alter the suite selection depending on the negotiated protocol version, which may or may not be an available option for your particular SSL server.

If BEAST does not apply to you (the client will not run hostile code), then drop RC4 support altogether; concentrate on AES-128 and SHA-256; fallback on 3DES and SHA-1, respectively; use DHE if available.

  • 6
    Given recent revelations, I think security professionals should be encouraging people to use ciphersuites with perfect forward secrecy, e.g., ECDHE or DHE. Should this list be updated, to recommend use of them (over TLS_RSA_WITH_RC4_128_SHA)?
    – D.W.
    Commented Sep 6, 2013 at 21:57
  • 1
    This kind of post should be kept up to date in order to maintain the same level of quality and accuracy over time.
    – ATo
    Commented Aug 20, 2016 at 19:59

Where are fixes and what could they look like? Only fix would be that all Browsers on all relevant plattforms get TLS 1.1 or 1.2 implemented. However, I don't beleive this will happen for legacy plattforms like.

So for now I only seen RC4 as a work-around as most SW developers missed out to implement the latest TLS standards in the past and now we are caught in the situation as is.


I like the cipher suite proposed by Mozilla (In January, 2014):


source: https://wiki.mozilla.org/Security/Server_Side_TLS

it tries to balance performance and security. However, as recommended my Microsoft, I would stay away from RC4


Update 2016 via SSL Labs:

You should rely chiefly on the AEAD suites that provide strong authentication and key exchange, forward secrecy, and encryption of at least 128 bits. Some other, weaker suites may still be supported, provided they are negotiated only with older clients that don't support anything better.

There are several obsolete cryptographic primitives that must be avoided:

Anonymous Diffie-Hellman (ADH) suites do not provide authentication.

  • NULL cipher suites provide no encryption.
  • Export cipher suites are insecure when negotiated in a connection, but they can also be used against a server that prefers stronger suites (the FREAK attack).
  • Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken.
  • RC4 is insecure.
  • 3DES is slow and weak.

Use the following suite configuration, designed for both RSA and ECDSA keys, as your starting point:


Note This example configuration uses nonstandard suite names required by OpenSSL. For deployment in other environments (e.g., IIS), you'll need to use the standard TLS suite names.

Reference: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

  • Please order the cipher list. AES-256 should be preferred over AES-128. Commented Oct 19, 2018 at 21:27

Let's look at ciphers disregarding the BEAST attack first.

I'd recommend only using 'current' ciphers with strong keys, and not supporting historic ciphers that nobody uses anyway. So no RC4 for instance. Also, I'd recommend against export-level ciphers, these have very weak keys so that the US government might be able to break them. Although I believe exporting higher-grade crypto is no longer illegal, the concept still exists in your server config. Finally, avoid hashing algorithms that have big problems, like MD5.

Now the BEAST attack.. apparently, AES in CBC mode as used in TLS 1.0 is vulnerable to a chosen plaintext recovery attack. mail.google.com defended against this by quickly switching to 128 bits RC4 this week. If you're very concerned about this attack in the coming 2 weeks (like google would be), you could apply the same workaround. In other cases, I'd simply wait for a fix, and configure your ciphers without regarding this attack.

  • 2
    RC4 is widely supported, and there are browsers that offer it as a preference. Also, if the attack is as bad as advertised, it's a very serious break, so I wouldn't be comfortable with a blanket recommendation to sit back and wait for a fix. Commented Sep 23, 2011 at 18:01
  • You know a lot more about crypto than I do, but wouldn't an attacker in the position to perform BEAST have many other more attractive options, with more impact? Also, don't you expect browser vendors will quickly patch the vulnerability like Chrome did?
    – chris
    Commented Sep 24, 2011 at 10:47
  • Whether or not clients patch is not entirely the point - servers have an independent need to protect themselves from attackers, even in the face of vulnerable clients. There are always other ways to attack someone, but that doesn't mean that this one doesn't need to be addressed, of course. Commented Sep 25, 2011 at 15:17
  • @JeffFerland that's what I mention in the answer right?
    – chris
    Commented Sep 27, 2011 at 20:31
  • Ah, yes... but after "So no RC4 for instance"... sometimes I shortcut posts when I see info like that showing up.
    – Jeff Ferland
    Commented Sep 27, 2011 at 20:33

You may find some interesting configuration for apache2 & strong SSL algorithm selection here:

Mozilla SSL Configuration Generator https://mozilla.github.io/server-side-tls/ssl-config-generator/

The 2019.02 recommendation for modern browsers is:




You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .