3
$\begingroup$

Following ciphersuites found to be weak in Qualys(https://www.ssllabs.com/ssltest/analyze.html) tool:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH x25519 (eq. 3072 bits RSA) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH x25519 (eq. 3072 bits RSA) TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 4096 bits
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 4096 bits

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH x25519 (eq. 3072 bits RSA) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH x25519 (eq. 3072 bits RSA) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 4096 bits TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits

Why these ciphers are found to be weak?

$\endgroup$
2

2 Answers 2

3
$\begingroup$

These are considered weak ciphers, and are potentially vulnerable to the BEAST attack: https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack

In general there have been a set of attacks on CBC ciphers in SSL/TLS (like poodle), we have seen attacks on timing and padding.

In recent years most seem to prefer GCM mode.

For practical advice, Use TLS1.2 at least. Also may prefer to exclude the various CBC modes. In TLS1.3 they removed CBC entirely(and have much fewer cipher suits reducing the attack surface significantly).

$\endgroup$
2
  • 2
    $\begingroup$ The first 4 suites in the Q are 1.2-only so OP apparently is using 1.2. BEAST only applied to (CBC in) SSL3 and 1.0; POODLE was mostly SSL3 although bugs have been found in implementations of newer protocols. The (only) unavoidable attack on (non-EtM) CBC in 1.2 is LuckyThirteen, which isn't really practical, but is still considered reason enough to avoid it (and prefer AEAD, but not necessarily GCM; CCM and ChaCha/Poly are also available). $\endgroup$ Commented Dec 10, 2022 at 1:54
  • 1
    $\begingroup$ @dave_thompson_085 Lucky 13 is practical in some real settings. It's avoidable if you're prepared to pay the performance penalty. OpenSSL and many other popular implementations implement the countermeasure. $\endgroup$ Commented Dec 12, 2022 at 20:43
1
$\begingroup$

All these cipher suites use CBC mode, which requires padding. Padding, unless used very carefully, makes encryption vulnerable to padding oracle attacks. TLS uses CBC in a MAC-then-encrypt construction, and even one that somewhat goes out of its way to make padding oracle attacks easier, because the padding can be up to 256 bytes long.

TLS CBC cipher suites are vulnerable to the Lucky Thirteen attack. This is an implementation vulnerability: not all implementations are vulnerable to this attack. However, to protect against Lucky 13, an implementation needs to take special precautions, and these precautions make decryption significantly slower (you have to calculate up to 256 MAC values for every packet instead of just one). OpenSSL and several other popular implementations implement the necessary countermeasure, but there are other popular implementations that are vulnerable.

There is an extension to the TLS protocol called encrypt-then-MAC (EtM), which does exactly what the name suggests. With encrypt-then-MAC, only authentic ciphertexts are ever decrypted, so no padding oracle attack is possible. EtM requires both sides to support the extension, and not many TLS implementations support it, so it's of limited practical applicability. Furthermore, a lot of software that uses TLS lets the administrator configure which cipher suites are permitted, but doesn't have a control for “only permitted with EtM”, so it's hard to enforce that EtM must be used.

The easiest way to rule out attacks on CBC is to not use CBC. Restrict to cipher suites that use proper AEAD: GCM, CCM, or Chacha20+Poly1305. If you absolutely must use CBC cipher suites because some of your machines still use some antique crypto engine that doesn't support 21st century modes, make sure that all your TLS implementations either support EtM or (as a last resort due to the performance penalty) implement the Lucky 13 countermeasure.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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