59

Why does SSL labs now mark CBC 256 suites as weak, although equivalent GCM and ChaCha20 are considered strong? Until a few months ago, it was unmarked in reports (neither explicitly as weak or strong), and it is still unmarked in their client lists.

The suites in question are:

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA

The SHA1s are a requirement to support Android 5 and 6 with 4x100% score. It still gets 4x100% score, but it marks it as weak, which from an OCD perspective doesn’t look “professional”.

Improve this question
2
  • TLS v1.3 prefers authenticated encryption modes of operation for block ciphers, like GCM mode. AuthEnc modes have been available since TLS v1.1, if I recall correctly. ChaCha20 is a stream cipher, and it is not operated in a mode per se, so warnings about CBC mode do not apply.
    – user29925
    Commented May 13, 2019 at 17:14
  • @jww TLS 1.3 only supports authenticated encryption, null ciphers, block ciphers (such as AES-CBC) and stream ciphers (such as RC4) are no longer possible. Authenticated encryption is only available since TLS 1.2 and is defined in RFC 5246, Section 6.2.3.3. It cannot be used with TLS 1.1 and before.
    – Lekensteyn
    Commented May 14, 2019 at 21:12

2 Answers 2

Reset to default
60

While CBC is fine in theory, there is always the risk that an improper implementation will subject the connection to padding oracle attacks. Time and time again, CBC implementations in TLS have shown themselves to be vulnerable, and each time an implementation is fixed, it seems yet another bug making padding oracle attacks feasible appears. Lucky Thirteen was published in 2013, and variants of this attack based on side channels keep popping up. SSL Labs is just observing history and learning from it.

Improve this answer
2
  • So would you consider it to be secure enough for a production server? It seems like the only way to support Andoird 5 and 6. Other ciphers they work with are old implementations of ChaCha20, DES, 3DES, and 128b CBC and GCM (and RC4). It doesn't look like there's a better solution.
    – Martin Horský
    Commented May 13, 2019 at 10:46
  • 10
    From our server logs I can see a lot of Android 5 devices using either ECDHE-RSA-AES128-GCM-SHA256 or ECDHE-RSA-CHACHA20-POLY1305. So even though these ciphers are not part of the API for Android 5, they seem to be available on a number of devices.
    – Gert-Jan
    Commented May 13, 2019 at 11:38
31

Simply put, after four new CBC-exclusive attacks have been revealed, all padding oracle attacks, they want to discourage it, as per a comment from the author of the update blogpost:

We are only encouraging to move away from CBC based cipher suits after 4 new CBC based vulnerabilities. As of now, there is no grade change for CBC and servers can continue to use.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .