15
$\begingroup$

I have a small embedded platform that supports 6 TLS ciphers. Is there a good/better/best one to chose?

I was looking around on the web for some kind of rating system or list of ciphers that have known weaknesses, but I couldn't find much.

Back to my project, I used the Wireshark tool to capture the "client hello" when authenticating with the server, and my (slim) options are as follows:

  • TLS_RSA_WITH_RC4_128_SHA (0x0005)
  • TLS_RSA_WITH_RC4_128_MD5 (0x0004)
  • TLS_RSA_WITH_AES_128_CBC_SHA (0x002F)
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000A)
  • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

I have heard triple DES, RC4, and MD5 are insecure, so should I be avoiding ciphers with those algorithms? Does this leave me with cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_DSS_WITH_AES_128_CBC_SHA?

Improve this question
$\endgroup$
2
  • 4
    $\begingroup$ TLS_RSA_WITH_AES_128_CBC_SHA is probably the one to go with. $\endgroup$
    – Stephen Touset
    Dec 29, 2016 at 6:01
  • 5
    $\begingroup$ @StephenTouset You may be right, but please only post this kind of thing as a well described answer, just shouting out a specific cipher suite is not very helpful in my opinion (and discussing it here therefore makes no sense). $\endgroup$
    – Maarten Bodewes ♦
    Dec 29, 2016 at 15:54

4 Answers 4

Reset to default
12
$\begingroup$

Ideally, you should not use any of them. At all.

Here's why.

  • RC4, MD5 and DES should not be used anymore. Old crypto. Toss it.
  • CBC mode in AES sometimes suffers from implementation problems (cf. Padding Oracles). Thus, CBC should be avoided.
  • SHA1 is considered insecure and is not be accepted as a certificate signing hash since January 2017 by major browsers.

So, if you absolutely have to stick with one of these ciphers, I agree with @otus here, and would recommend TLS_DHE_DSS_WITH_AES_128_CBC_SHA.

IF ever you have a chance to add other ciphers to your embedded platform, know this :

Symetric ciphers :

  • AES and ChaCha20 are the best symmetric ciphers to use, as of the beginning of the 21st century. The difference between them is, simply put, being a block and stream cipher, therefore being different in speed.
  • AES often takes advantage of AES-NI, a hardware acceleration, found on many processors in current laptops and servers.
  • ChaCha20 is to be preferred on mobile and embedded platforms, where AES hardware acceleration is rare, because it is really faster.
  • Poly1305 is de facto the best buddy for ChaCha20, so they go in pair.
  • For AES, consider AEAD compatible modes, like GCM.
  • Chose a hash algorithm like SHA2 or above (SHA384, SHA512,...). The higher, the more secure. But this is overkill, will take more time and is heavier in terms of size. So stick with SHA256.

Asymmetric ciphers (for key exchange) :

  • Today's trend and best use is Diffie-Hellman. Even better, Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE), because it is smaller, faster (you can generate 384bit parameters in a couple of milliseconds, corresponding to 7680 non-EC bits that would take hours to generate on your embedded device).

Certificate Signing :

  • Nobody uses DH.

  • RSA was good. To be avoided from now on. is still good.

    It's even really faster for validation than DSA - take a look with openssl speed (up to you to determine whether this matters for your use).

  • Best use : ECDSA. DSA is new, and coupled with Elliptic curves, it is smaller and really faster than RSA - take another look at openssl speed. Considered more secure. Just a shame that Edwards curves are not supported in OpenSSL as for now.

(Sorry if I missed details or am not being clear, wrote this on lunch break.)

EDIT : Added clarification on choice between ECDSA and RSA. Thanks @Dreadlockyx and @otus for having me have a second look !

Improve this answer
$\endgroup$
5
  • $\begingroup$ I don't really understand why RSA should be put aside in favor of (EC)DSA, as it relies too much on RNGs, which can be insecure at times. EdDSA is actually the way to go. $\endgroup$
    – Dreadlockyx
    Jan 2, 2017 at 14:20
  • 2
    $\begingroup$ SHA-1 is deprecated for certificate signing, but in cipher suites it is ok. Also, why do you think RSA should be avoided in cert signing? $\endgroup$
    – otus
    Jan 2, 2017 at 14:46
  • $\begingroup$ I agree with both of you. EdDSA is, for now, not supported in OpenSSL. +1 about the RNGs. For RSA you're both right, I might have been a bit extremist on that one, was going with the flow. RSA is effectively faster than DSA on validation, thus being a better choice from a client perspective. I am going to add these precisions, thanks! $\endgroup$
    – Bytemare
    Jan 9, 2017 at 3:29
  • 1
    $\begingroup$ @lahwran it's relatively new, compared to RSA. $\endgroup$
    – Bytemare
    May 24, 2019 at 18:10
  • $\begingroup$ Whoops, my intended claim that DSA was outdated is wrong anyway, I was thinking of DES. $\endgroup$
    – lahwran
    May 24, 2019 at 22:12
11
$\begingroup$

RC4 sucks.

3DES sucks too, but a bit less than RC4.

AES does not suck. The "CBC" part is kinda sucky, but less than 3DES (which has CBC too anyway) and it can be fixed with proper implementations.

DHE provides forward secrecy, a highly fashionable but somewhat overhyped property. It's nice to have, unless it comes with undesirable side effects. In your list, use of DHE implies the following side effects:

  • DHE works on Diffie-Hellman parameters which are a usual sore point of security and interoperability. Some old systems cannot cope with DHE parameters of more than 1024 bits, while others will reject DHE parameters of less than 2048 bits. Clients cannot make sure that the server-chosen parameters are really good (and some are really bad). Some implementations will reject DHE parameters unconditionally, unless they are standardised parameters announced with an extension that nobody implements (maybe they will, in the future, or not).

  • In your case, DHE is DHE_DSS: this means your server private key will have to be of type DSS. Nobody does that. If your system is the client, then it is highly improbable that any server you try to talk to will have a DSS key. Back in 2013 I randomly scanned more than 2 million IP addresses, on port 443, and located about 16000 SSL/TLS servers. Of these, exactly 6 had DSS keys (and for some of them the certificates were expired). If your embedded system is the server, then good luck with obtaining a certificate with a DSS key from a commercial CA.

This leaves you, basically, with only TLS_RSA_WITH_AES_128_CBC_SHA. Not the best cipher suite ever, but serviceable. If you use that one, then it is highly improbable that when your system get thoroughly hacked into, it will be because of a poor cipher suite choice.

Improve this answer
$\endgroup$
10
$\begingroup$

None of them are optimal, but only the RC4 ones are clearly broken.

  • RC4 has been deprecated and should be disabled (see RFC 7465).

  • Both 3DES and AES are fine, though the latter is preferable in practice due to its speed and larger block size.

  • Suites with DHE_DSS are preferable over plain RSA (when keys and parameters are of sufficient size) because they have forward secrecy. (Assuming you can use them. Thomas Pornin has a point regarding limited support.)

  • CBC is not optimal because clients may be vulnerable to BEAST and the like, but it has been fixed for a long while, so unless you use some ancient software – or expect it on the other end – it should be okay.

That means I would use TLS_DHE_DSS_WITH_AES_128_CBC_SHA, but the other three non-RC4 ones are not bad either.

Improve this answer
$\endgroup$
3
  • 3
    $\begingroup$ Given that the DH and DSS keys are of sufficient strength. Quite often RSA is offered with higher key strength than those options. I.e. with DH and DSS keys stuck at 1024 bits and RSA using 2048 bits, you may want to consider RSA. $\endgroup$
    – Maarten Bodewes ♦
    Dec 29, 2016 at 15:51
  • $\begingroup$ @MaartenBodewes, true, adding. $\endgroup$
    – otus
    Dec 29, 2016 at 20:23
  • 2
    $\begingroup$ 3DES also has a disadvantage that if you encrypt multimegabytes of data, you have the possibility of leaking a small amount of information about the plaintext. This isn't much of a leakage, however it's another reason to prefer AES. $\endgroup$
    – poncho
    Dec 29, 2016 at 22:37
-1
$\begingroup$

You should use one of these two:

  • TLS_RSA_WITH_AES_128_CBC_SHA (0x002F)
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)

The reasons are, as you have said, the rest combinations use insecure algorithms. RC4, DES, and MD5 have been vulnerated and they are not the last version of each one.

Improve this answer
$\endgroup$
14
  • 4
    $\begingroup$ Note that the cipher suites in question do you 3DES instead of DES. $\endgroup$
    – SEJPM
    Dec 29, 2016 at 9:38
  • 2
    $\begingroup$ I wouldn't say that crypto algorithms have versions (MD5,MD6 etc.), they are just separate algorithms (versions might be in Whirlpool which is same algorithm with tweaks). Nevertheless good answer +1. $\endgroup$
    – axapaxa
    Dec 29, 2016 at 14:11
  • 2
    $\begingroup$ @CGG, you did not fix the answer. On the contrary, now it is wrong, since COPACOBANA cannot brute force 3DES. $\endgroup$
    – otus
    Dec 29, 2016 at 14:27
  • 2
    $\begingroup$ RC6 is not a version of RC4, despite the name. Totally different designs! $\endgroup$
    – Henno Brandsma
    Dec 29, 2016 at 15:37
  • 2
    $\begingroup$ MD5 has pre-image attacks but with a complexity of $2^{123}$ they are not directly something to worry about in practical protocols. And as MD5 is used here for the PRF (i.e. HMAC) you do not need to worry about collision attacks within the cipher suite (although the use of MD5 for signature generation / verification is of course a different matter). Not that I would recommend TLS_RSA_WITH_RC4_128_MD5 of course. $\endgroup$
    – Maarten Bodewes ♦
    Dec 29, 2016 at 15:59

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.