Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

up vote 25 down vote accepted

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.

share|improve this answer
3  
Thanks! I've been looking all over the internet, you're the only person to give information that allows me to make a (somewhat) informed decision, instead of just giving some non-argued recommendation. –  Jacco Oct 2 '12 at 7:49
3  
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. Sep 6 '13 at 21:57

I like the cipher suite proposed by Mozilla:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256: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-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

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

share|improve this answer

This Microsoft Security announcement says you should configure your server to use TLS and use RC4. Not being a cryptologist, but by simply looking at this table I think that means the following are safe:

Windows 2008 Server, R2, Win7 and Vista

  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_RC4_128_MD5
  • SSL_CK_RC4_128_WITH_MD5

Can anyone else look at that table and tell me what additional ones I would need to configure through GPO?

share|improve this answer
2  
Don't use the _40_ or _56_ ciphersuites! They are massively insecure, as they offer only 40 bits or 56 bits of security. They existed only for export purposes, back when US export law made it very difficult to export software containing full-strength crypto. No one should use them today. –  D.W. Jun 13 '13 at 15:51
    
@D.W. I removed those entries –  makerofthings7 Jun 17 '13 at 17:29
1  
makerofthings7: Re: GPO - ask a question, please. You know the score :) –  Deer Hunter Jun 17 '13 at 18:04

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.

share|improve this answer

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.

share|improve this answer
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. –  Steve Dispensa Sep 23 '11 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 Sep 24 '11 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. –  Steve Dispensa Sep 25 '11 at 15:17
    
@JeffFerland that's what I mention in the answer right? –  chris Sep 27 '11 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 Sep 27 '11 at 20:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.