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,132
  • 5
  • 70
  • 165
user554242
  • 153
  • 1
  • 1
  • 6
  • 4
    TLS_RSA_WITH_AES_128_CBC_SHA is probably the one to go with. – Stephen Touset Dec 29 '16 at 06:01
  • 5
    @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). – Maarten Bodewes Dec 29 '16 at 15:54

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
  • 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. – Dreadlockyx Jan 02 '17 at 14:20
  • 2
    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? – otus Jan 02 '17 at 14:46
  • 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!

     – Bytemare Jan 09 '17 at 03:29
  • 1
    @lahwran it's relatively new, compared to RSA. – Bytemare May 24 '19 at 18:10
  • Whoops, my intended claim that DSA was outdated is wrong anyway, I was thinking of DES. – lahwran May 24 '19 at 22:12
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
  • 86,974
  • 16
  • 242
  • 314
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,132
  • 5
  • 70
  • 165
  • 3
    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. – Maarten Bodewes Dec 29 '16 at 15:51
  • @MaartenBodewes, true, adding. – otus Dec 29 '16 at 20:23
  • 2
    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. – poncho Dec 29 '16 at 22:37
-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
  • 8
  • 15
  • 4
    Note that the cipher suites in question do you 3DES instead of DES. – SEJPM Dec 29 '16 at 09:38
  • Thank you for your correction SEJPM. I have corrected my answer. – CGG Dec 29 '16 at 10:22
  • 2
    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. – axapaxa Dec 29 '16 at 14:11
  • 2
    @CGG, you did not fix the answer. On the contrary, now it is wrong, since COPACOBANA cannot brute force 3DES. – otus Dec 29 '16 at 14:27
  • 2
    RC6 is not a version of RC4, despite the name. Totally different designs! – Henno Brandsma Dec 29 '16 at 15:37
  • 2
    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. – Maarten Bodewes Dec 29 '16 at 15:59
  • @HennoBrandsma RC6 is the successor of RC5, and RC5 is the alternative to RC4, RC4, RC5, and RC6 was designed by Ron Rivest. For these and other things I have understood that RC6 is an evolution of RC5 and RC4. – CGG Dec 29 '16 at 20:32
  • @MaartenBodewes. Ok, I agree with you that is very difficult to obtain a practical attack but it is a vulnerability. Besides, MD5 has more vulnerabilities. I am going to add more articles now. – CGG Dec 29 '16 at 20:35
  • 1
    @CGG The only thing that is common between RC4 and RC5 is the designer. RC6, though, can be seen as a successor to RC5. For MD6 vs MD5, again, they have very little in common except for their author. MD6 is slow as Hell, and when it competed for SHA-3 the authors themselves desisted. – Thomas Pornin Dec 30 '16 at 02:59
  • Also, no 3DES instance was ever brute-forced. DES instances were; brute-forcing a 3DES key is (exactly) 15576890575604482885591488987660288 times harder than brute-forcing a DES key (this figure is exact). – Thomas Pornin Dec 30 '16 at 03:02
  • @ThomasPornin. What happens because MD5 and MD6 are different? From my humble opinion, that is normal because they wanted to create a new and better algorithm. MD6 is the new MD5 version, MD6 is the evolution of MD5. I know that they proposed MD6 to SHA3, I have read the whole article with all the vulnerabilities and problem that the NIST encountered in MD6. The problem here is that MD5 has vulnerabilities. Maybe they are more easy or hard to do with any computer but are vulnerabilities. – CGG Dec 30 '16 at 10:51
  • @ThomasPornin Here, the author has asked about a secure algorithm. Then, the first requirement is the security, not the speed. Then, for me, I prefer a secure and slow algorithm instead a bad but quick algorithm. – CGG Dec 30 '16 at 10:53
  • @CGG If you want to use a secure algorithm then you'd choose SHA-3, i.e. Keccak, which doesn't contain the aforementioned issue. MD6 is not a drop in replacement for MD5 anyway (as the output size of MD5 is not considered secure anymore, to name just one issue). The same for 3DES -> AES and RC4 -> Salsa20 or simply AES, preferably using GCM mode. – Maarten Bodewes Dec 30 '16 at 13:01
  • @MaartenBodewes Clearly, I agree with you with that, the best choice is SHA3 and AES. I know it, but here we were talking about these combinations. If you ask me about another combination I will always choose SHA3-512, AES-256, and RSA-4096. – CGG Dec 31 '16 at 11:32