[BUG / possible BUG] The difficulty with LUCKY13 / CVE-2013-0169

[andy-maier]

Before you open an issue please check which version you are running and whether it is the latest in stable / dev branch

I am running version testssl.sh 3.0.8 from https://testssl.sh/.

This issue is related to several others where LUCKY13 was suspected to be a false positive (#1181, #1011), or where people reported it without providing enough information.

Command line / docker command to reproduce

testssl.sh https://localhost:9291

Port 9291 is the Prometheus server port provided by the zhmc prometheus exporter (https://github.com/zhmcclient/zhmc-prometheus-exporter), configured to use HTTPS. This is a Python project that uses the https://github.com/prometheus/client_python Python library version 0.20.0 for the HTTPS server. That Python library uses the Python ssl module directly, with the default set of ciphers (see below for OpenSSL version). Note that the default set of ciphers at the Python level is a subset of what openssl ciphers reports.

Using the default set of ciphers, testssl.sh reports this:

LUCKY13 (CVE-2013-0169), experimental     potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches

I then modified the code of the Prometheus client library to display the default set of ciphers, and that revealed 4 ciphers that are CBC ciphers (according to https://security.stackexchange.com/q/210912/136814):

• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256

When modifying the code of the Prometheus client library to remove these 4 ciphers from the Python SSL context, testssl.sh was happy w.r.t. LUCKY13:

LUCKY13 (CVE-2013-0169), experimental     not vulnerable (OK)

See here for the code that removes the ciphers: prometheus/client_python#1051

Expected behavior

I think there are some difficulties for the average user with the current LUCKY13 vulnerability message:

• It does not list the names of the ciphers that it complains about. This makes it difficult, particularly since the CBC ciphers that (at least in my case) lead to solving the vulnerability finding did not have "CBC" in their name.
• The phrase "potentially VULNERABLE" along with the many closed issues and some issues that claim (incorrectly) a false positive leave people confused as to how important it is and what to do about it. Apparently testssl.sh can distinguish the case where the server provides CBC ciphers and where it does not do that (otherwise my removal of the 4 CBC ciphers would not have made testssl.sh happy). If the server provides CBC ciphers, it is vulnerable, right? Not just potentially vulnerable.

Do you think it makes sense to change the following:

• List the ciphers that caused testssl.sh to raise the LUCKY13 vulnerability message.
• Remove "potentially" from the LUCKY13 vulnerability message.

Your system:

• OS: macOS 13.6.7
• Platform: Darwin 22.6.0 x86_64
• OpenSSL: Using "OpenSSL 3.3.0 9 Apr 2024 (Library: OpenSSL 3.3.0 9 Apr 2024)" [~69 ciphers]
• Bash: GNU bash, version 5.2.15(1)-release (x86_64-apple-darwin21.6.0)

Additional context

None

[drwetter]

Thanks for the lengthy explanation.

This particular check is admittedly a while back when it was written. CBC ciphers were hard to avoid by that time and there was this difficult to exploit weakness . IIRC all TLS stacks added some milli seconds to avoid exploitation of the timing issue. That's why I believe "potentially" should not be removed.
Why do you think it should?

Yeah, we could add the ciphers.

[aff]

The LUCKY13 timing attack was mitigated in most TLS implementation a decade ago [1,2]. While able to detect potentially vulnerable CBC ciphers, testssl fails to differentiate between potentially and actually vulnerable implementations. This leads to a very high false positive rate in practice, which in turn reduces the trustworthiness of the otherwise excellent tool.

I propose to deprecate LUCKY13 testing altogether.

[1] https://web.archive.org/web/20200324101422/http://www.isg.rhul.ac.uk/tls/Lucky13.html
[2] https://aws.amazon.com/blogs/security/s2n-and-lucky-13/

[drwetter]

@aff : yes, and in addition it was not practical to be exploited remotely. Probably it makes sense to remove that at version >3.2 . Or what do you mean by "deprecate"? Bigger changes will take place 3.3+

In the meantime: the finding is labeled as LOW severity finding and it says potentially and is referring to patches to be checked. If you have a more catchy description I am all ears ;-)

[k01294]

@drwetter; By "deprecate" I mean remove. I will wait patiently if larger changes are coming. Thank you very much for your public service.

[Tazmaniac]

Until TLS1.2 is deprecated and banned, you could not remove the test.
There is still unpatched really vulnerable stacks in the wild even if it is in practice a LOW severity. So the "potentially vulnerable" still apply. This is not a false positive "potentially vulnerable" != "vulnerable" and it help to get rid of CBC ciphers.
As the cipher denominations in openssl are not as precise as the IANA (or gnutls) ones, naming explicitly the offending ones would be great.