Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed CBC ciphers to address CVE-2013-0169 (LUCKY13) #1051

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

andy-maier
Copy link
Contributor

Details:

This change removes the following CBC ciphers from the default set of ciphers in order to address CVE-2013-0169 (LUCKY13):

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

This is done by listing them in the code, i.e. without any way to configure that by the user.

The LUCKY13 vulnerability was discovered using the testssl.sh tool. See also drwetter/testssl.sh#2537

@andy-maier
Copy link
Contributor Author

andy-maier commented Jul 29, 2024

If there is anything I can do in the PR for the failing CircleCI tests test-3.8 and test-3.9, let me know.

Update: Force-pushing the PR helped.

Details:

* This change removes the following CBC ciphers from the default set
  of ciphers in order to address CVE-2013-0169 (LUCKY13):
  - ECDHE-ECDSA-AES256-SHA384
  - ECDHE-RSA-AES256-SHA384
  - ECDHE-ECDSA-AES128-SHA256
  - ECDHE-RSA-AES128-SHA256
  This is done by listing them in the code, i.e. without any way to
  configure that by the user.

Signed-off-by: Andreas Maier <maiera@de.ibm.com>
Copy link
Member

@csmarchbanks csmarchbanks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love this library needing to worry about ciphers and keeping up to date with them. I think I would be ok with providing functionality to allow a user to specify the list of ciphers they want to support, but even that is getting into the territory where they should consider just standing up their own HTTP server instead of the lightweight one we provide.

@andy-maier
Copy link
Contributor Author

@csmarchbanks I know. I don't like it either, but the big advantage of the provided HTTP server is that it is built-in, simple to use, and it works great, even for our exporters that can have large amounts of metrics.

And I think you don't need to worry about checking for such things yourself, as users will bring it up, and may even fix it, like in this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants