15

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?

otus
  • 32,462
  • 5
  • 75
  • 167
user554242
  • 153
  • 1
  • 1
  • 6

4 Answers4

12

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 !

Community
  • 1
Bytemare
  • 138
  • 5
11

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.

Community
  • 1
Thomas Pornin
  • 88,324
  • 16
  • 246
  • 315
10

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.

Community
  • 1
otus
  • 32,462
  • 5
  • 75
  • 167
-1

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.

CGG
  • 229
  • 1
  • 9
  • 16