I have a webserver which only supports TLS 1.0 and I am not sure about something: Which is the better cipher in this group when aiming for the best security?


I chose only ciphers with ECDHE for Perfect Forward Secrecy. Speed is not very important, for me secure is more important.

These ciphers are used in my Java application for retrieving data from a HTTPS website. My doubt was due to the fact that the CBC Ciphers are vulnerable to BEAST Attacks.

  • $\begingroup$ I'm assuming you don't really want NULL as that means no confidentiality (in other words your data is sent unencrypted). I'd avoid RC4. As to what is left, what are your goals? How important is speed? In other words, what does "better" mean? Does your processor support AES-NI? Why only SHA and nothing from SHA2 family? $\endgroup$ – mikeazo Jan 17 '14 at 14:16
  • $\begingroup$ At minimum you can eliminate 3DES, it's strictly worse than AES. And NULL is obviously not useful either when you're interested in confidentiality. $\endgroup$ – CodesInChaos Jan 17 '14 at 14:45
  • $\begingroup$ Well, if you are interested in "best security", you should probably use anything with AES and SHA at the end, the rest is kinda personal preference: AES 128 and AES 256 are both considered secure, it depends mostly on how large your blocks should be. Choosing RSA or ECDSA as signature algorithm is both fine (it depends more on the according parameters to achieve a secure level) $\endgroup$ – tylo Jan 17 '14 at 16:57
  • 2
    $\begingroup$ @tylo: nit: AES-128 and AES-256 has the same block size; they differ in the size of their keys. $\endgroup$ – poncho Jan 17 '14 at 17:16
  • 2
    $\begingroup$ @GiovanniNervi Some clients are vulnerable to BEAST. The rest have implemented workarounds even on TLS 1.0. I consider BEAST to be a smaller issue than RC4 sucking. $\endgroup$ – CodesInChaos Jan 17 '14 at 17:34

The best option you have is TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA.
This is likely to provide most security, as the AES keylength is maximal and ECDSA keys tend to provide more security than RSA keys, as a 128-bit security level is quite common with ECDSA (field size: 256 bit) whereas 112-bit is the standard with RSA (keylength: 2048 bit).

However in practice TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA may be easier to deploy as RSA certificates are usually a lot cheaper and easier to get.

To get even further you're also fine with TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as a 128-bit key is quite common today and chances are your ECDH group also provides "only" 128-bit security, meaning you can get higher speed without sacrificing security.

As explained in the comments by CodesInChaos you should definitely avoid RC4, which is also officially banned from TLS as per RFC 7465. To repeat what CodesInChaos said: The CBC-suites are less an issue than RC4 because ...

  1. modern browsers mitiagate BEAST (CBC-based attack) even on TLS 1.0
  2. BEAST is an active attack, whereas RC4 already falls due to passive attacks
  3. BEAST is hard to exploit in practice and relevant features seem to have been removed.

This removes the TLS_ECDHE_RSA_WITH_RC4_128_SHA and TLS_ECDHE_ECDSA_WITH_RC4_128_SHA ciphersuites from the list. You should also avoid 3DES, as it provides "only" 112-bit security, but is significantly slower than AES making it inferior in every aspect, so you shouldn't choose TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA nor TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA.

However, if possible you should migrate to TLS v1.2 (or newer). There you should avoid all cipher suites not finishing with ..._SHA256 or _SHA384 as the other ones use SHA-1 which is deprecated. Furthermore TLS v1.2 (or newer) allows (v1.3 will force) you to use non-CBC mode ciphers, especially AEAD ciphers, which don't suffer from BEAST or similar attacks. This means that as of now the best choice (in terms of security) for the cipher suite is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 not being a lot weaker. If possible you should prefer ECDSA (or EdDSA) over RSA although RSA can be sufficiently secure when using appropriate keylengths.

  • 1
    $\begingroup$ Voted this up, but please make sure that the analysis is still valid in the future, and try to move to TLS 1.2 or 1.3 (when it is out) if you can. $\endgroup$ – Maarten Bodewes Jul 12 '15 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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