I need some guide to decide in which order I must put the following ciphers if I want prioritize security and in cases of tied, consider performance to decide.

ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384

And what about this list?

DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256

different list, I don't want mix them ;)

  • 1
    You can already scratch half of them as you likely have a RSA certificate for which the ECDSA and DSS ciphers do not work.
    – Lekensteyn
    Oct 4, 2013 at 15:43
  • @Lekensteyn Thanks for your comment. Anyway in my case is possible that we go with a self signed certificate cos our client base allow that. Your comment make me ask another question ;)
    – user30395
    Oct 4, 2013 at 17:22

2 Answers 2


Security: if you don't do stupid things like using a 512-bit RSA key, these cipher suites are all equally secure: they are all very far in the "cannot break it" zone. So that's a meh. You cannot say that one is more secure than any other.

With an exception though: the "ECDHE" suites use an ephemeral key pair for actual encryption; since the corresponding private key is never stored in a file, this grants a nifty property known as Perfect Forward Secrecy. Basically it makes communications immune to attackers who steal a copy of the server private key after the fact. PFS looks good in technical audits.

Performance issues exist only after having been duly measured. As Knuth said: Premature optimization is the root of all evil. So you should not ask such questions; you should try it out and measure. In any case, answer will depend a lot on the context: involved machines, bandwidth, usage patterns...

Short answer: won't matter.

Long answer:

The "GCM" cipher suites use GCM; the non-GCM cipher suites use AES in CBC mode and an extra HMAC (here, with SHA-384). Performance issues depend on the involved systems:

  • On small 32-bit systems (embedded ARM...), the MAC part of GCM will be expensive, but so will SHA-384 (because 64-bit computations...); I'd guess a tie.
  • On PC, AES cost will dominate;
  • ... except on very recent PC with AES-NI, where AES is very fast, and so is GCM.

So the GCM cipher suite should, usually, be a better bargain. However, it takes a lot of bandwidth, or a very small CPU, to actually notice the difference. Even without AES-NI, a normal server has enough juice to do SSL at full gigabit bandwidth, with CPU to spare.

For the asymmetric cryptography part:

  • The ECDHE suites imply on the server an (elliptic-curve) Diffie-Hellman and a signature for each full handshake, whereas the ECDH cipher suites require only the elliptic-curve Diffie-Hellman, and half of that one is already done.
  • ... But a normal PC will crunch through thousands of those per second and per code, so this very rarely matters.
  • ... Especially since normal SSL clients reuse SSL sessions, which means that the asymmetric cryptography occurs only for the first ever connection of the day from a given client.
  • ECDSA signatures are faster than RSA signatures.
  • ... Depending on key sizes, of course.
  • ... But for verification, this is the other way round.
  • ... And, again, it takes an awful lot of new clients per second for this to actually matter. A normal PC will do hundreds of 2048-bit RSA signatures per seconds, thousands of 256-bit ECDSA signatures per second.
  • ECDSA signatures are shorter than RSA signatures, so this saves a bit of network (but, again, only a few dozen bytes per full handshake).
  • DHE and ECDHE cipher suites also imply a few dozen extra bytes per full handshake.
  • DHE is like ECDHE but without the elliptic curves. You need it to use bigger mathematics to achieve the same security levels (2048-bit modulus instead of a 256-bit curve point), so it is like RSA vs ECDSA: a bit bigger, a bit slower, won't matter in practice.

So, really, you will not make a useful distinction based on security or even performance. In fact, you are already making a fashion statement, by insisting on AES-256 (instead of AES-128) and SHA-384 (instead of SHA-256). You may as well keep it on and bring it to its logical conclusion: use as much GCM and elliptic curves as possible ! This will grant brownie points from impressionable auditors.

  • Thomas you are amazing!
    – user30395
    Oct 4, 2013 at 16:52
  • +1 Very informational and in-depth answer, as always. Thanks Thomas!
    – Lekensteyn
    Oct 4, 2013 at 17:57

You should choose a suite depending on the application: for persisistent data such as emails you cannot use ephimeral keys because you need the keys to be stored in the server in order to decrypt the emails.

I also suggest to use RSA over ECDSA for your browser certificate compatibility.

(For pure information: ephemeral keys are not authenticated. If you want to avoid MITM attacks you need to obtain authenticity somewhere. You can use a static public key for example (so trusted by a certificate), then you thwart mitm.

To break one of those suites an eavesdropper must solve the discrete algorithm problem for DH (elliptic curve for ECDH) and the integer factorization problem for RSA. The best algorithms known to do so can be generalized for both the problems, thus they share the same asymptotic complexity.)

You must log in to answer this question.