TLS AES CBC ciphers not listed - False Negative

[rdurk]

Other tools and expert sources include the AES CBC cipher combinations as weak. That includes Qualys SSL test labs (https://www.ssllabs.com/) Tenable Nessus and CIS benchmarks. However using sslscan on up to date Kali is giving a false negative on AES CBC ciphers

Version: 2.0.10-static
OpenSSL 1.1.1l-dev xx XXX xxxx

SSL test labs and Nessus both list weak AES CBC ciphers allowed, however sslscan doesn’t even list them at all. The --show-ciphers option indicates the AES CBC ciphers shown below are available to sslscan.

SSLlabs output

TLS 1.2 (suites in server-preferred order)

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)   WEAK 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)   WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)   WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK 128

Where as sslscan lists

Supported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-384 DHE 384
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-384 DHE 384
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-384 DHE 384
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-384 DHE 384
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 256 bits AES256-SHA256
Accepted TLSv1.2 128 bits AES128-SHA256
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 128 bits AES128-SHA

sslscan --show-ciphers controlcenterservice.truveta.com:454 | grep TLS_RSA_WITH_AES_

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256

. . .

[rbsec]

Hi @rdurk,

Those ciphers are detected by OpenSSL (and are actually shown in your output) - the confusion is that the names that OpenSSL uses for some ciphers don't match the IANA names. So what OpenSSL (and thus sslscan) call AES256-SHA256 is called TLS_RSA_WITH_AES_256_CBC_SHA256 by ssllabs. There are various sites that provide mappings between the names, or you can verify by using the --show-ciphers-ids parameter, and check that the cipher ID matches (0x003D for the cipher above):

Accepted  TLSv1.2  256 bits    0x003D AES256-SHA256
Accepted  TLSv1.2  128 bits    0x003C AES128-SHA256
Accepted  TLSv1.2  256 bits    0x0035 AES256-SHA
Accepted  TLSv1.2  128 bits    0x002F AES128-SHA

In terms of flagging them, we list all the CBC ciphers are neutral (i.e, with no colour). There have certainly been vulnerabilities with them, but these were generally only applicable to TLSv1.0 (which has been flagged), or are fixed in modern implementations (such as Lucky13, which was patched against by OpenSSL and others in 2013). Perhaps that's something that should be revisited if there are newer attacks since that decision was made. @jtesta do you have any thoughts on that?

[rdurk]

Thanks @rbsec,

Thanks so much for explaining the openssl ids, and the mapping. That cleared things up for me. It’s good that the ciphers were detected. However it would be better to avoid confusion and use the IANA names as does the sslscan --show-ciphers option, the openssl ciphers command, as well as Qualys ssl test labs, Nessus and most other tools. Using the IANA name will make it clear which cipher & chaining combination is being used without having to use a webpage mapping.

Also the CBC cipher chaining, is considered a weak method of chaining the ciphers by the experts for years now. Would be good to warn people now before an exploit is developed. It takes a long time to get changes made in the TLS configurations used.

[rdurk]

Also thanks so much for maintaining sslscan! it's a really great tools used most of the security professional I know.

[rbsec]

The reason that the cipher naming is somewhat inconsistent is that sslscan relies on the SSL_get_cipher_name() OpenSSL function, which returns the OpenSSL names rather than the IANA ones up to TLSv1.2 (and then uses the IANA names for TLSv1.3 ciphers).

There was some discussion a while ago about changing to the IANA ones everywhere (#182), but this would mean creating our own mapping function, and would also create its own inconsistencies with OpenSSL (for example, if you try and list the ciphers, or correct with open s_client then the IANA cipher names won't work). The OpenSSL names are also used in a lot of third party applications that are based on OpenSSL (for example, if you try and configure Apache/Nginx/etc, or try and follow Mozilla's SSL hardening guide they all use the OpenSSL names.

It would also create inconsistencies with previous runs of sslscan - so if you scanned the same system you would (seemingly) get a completely different set of ciphers returned - and that would cause more issues.

I'm aware that CBC mode is considered weak and has been for years (hence why the ciphers are not flagged as "strong" in the output), but off the top of my head I can't think of any exploitable issues that affect those ciphers with a modern TLSv1.2 implementation. The biggest issue is that they don't support PFS - but I'm not really sure that's strong enough grounds to downgrade them. Is there a specific attack that you're thinking of that's relevant for them?

[rdurk]

Thanks for the quick reply. I don't know of any current attacks for TLSv1.2 with CBC ciphers, it is mostly the preference for the PFS. I went back and did some checking. SSLabs will still give an A+ rating for some sites, even while flagging the CBC usage as weak. Seems like a good compromise. Nessus has a plug-in specifically for CBC ciphers, but will show the risk as none, if TLS1.2 is used. Seems like it should be at least a low risk. It's unfortunate there isn't a reasonable way to bring the consistency to the names. In some cases the sslscan results doesn't show the openssl cipher id, so we have to match the whole name. When is it shown vs not shown? I use the sslscan output to explain to developers and sys admins how to test there systems.

[rbsec]

In some cases the sslscan results doesn't show the openssl cipher id, so we have to match the whole name. When is it shown vs not shown? I use the sslscan output to explain to developers and sys admins how to test there systems.

If you're referring to the hexadecimal ID of the cipher, it should be printed when you use the --show-cipher-ids flag. The actual cipher suite name come from the underlying library, which will use OpenSSL-style names (e.g, "ECDHE-RSA-AES128-SHA256") for TLSv1.2 and below, and will use IANA-style names (e.g, "TLS_AES_256_GCM_SHA384") for TLSv1.3.

Or did you mean something else?

[rdurk]

I was referring to the hex ids. Thanks.