Upgrade Bouncy Castle FIPS dependencies

[slobodanadamovic]

This PR updates bc-fips and bctls-fips dependencies to the latest minor versions.

[github-actions]

Documentation preview:

• ✨ Changed pages

[elasticsearchmachine]

Hi @slobodanadamovic, I've created a changelog YAML for you.

[slobodanadamovic]

@elasticmachine update branch

[h3xcat]

@slobodanadamovic Upgrading bc-fips to 1.0.2.5 invalidates FIPS compliance. The 1.0.2.5 version hasn't been certified for FIPS, and there are no future plans for that specific version to be certified according to library developers. Instead they recommend for applications to migrate to version 2.0.0, which was certified for FIPS.

bcgit/bc-java#1688 (comment)

https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4743 (certificate for 2.0.0)
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4616 (historic certificate for 1.0.2.4)

[jakelandis]

@h3xcat - We strive to keep Elasticsearch dependencies free from CVE's. This upgrade is to address CVE-2024-29857 , which Elasticsearch (the service) is not susceptible, out of the box, since Bouncy Castle is not shipped or configured (out of the box) as a JCE/JSSE provider. It is used in ancillary functions and for testing to ensure that our guidance for how to be compliant works. This change will update the dependency for those ancillary functions and which version we test against and our guidance for FIPS compliance. After internal discussion and a quick consult with a consultant we decided to proceed with the upgrade to the dependency.

There will always be a time difference between a CVE being reported and a FIPS module being able to be re-certified. So what is the appropriate action ? Ship/recommend a dependency with CVE(s); with certification vs. ship/recommend a dependency without CVE(s); not certified ? FedRAMP helps to answer that: https://www.fedramp.gov/updates/docs/cryptographic-module/ : "FedRAMP generally prefers use of an unvalidated module with no known vulnerabilities over the use of a known-vulnerable validated module." So that is the rationale to why we plan upgrade this dependency, and will be our general stance going forward. There are arguments to made both ways, but we believe that the default should be CVE free.

In this case, Bouncy Castle 1.x / FIPS 140-2 module (per bcgit/bc-java#1688 (comment)) will never be re-certified, but the point remains to prefer no vulnerabilities over the version in the certification. There are plans to upgrade our support to Bouncy Castle 2.0.0 with FIPS 140-3 compliance, but that will take a bit before that can be fully supported.

[jakelandis]

LGTM (pending CI)

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	8.17
✅	8.x

[mark-vieira]

💚 All backports created successfully

Status	Branch	Result
✅	8.16

Questions ?

Please refer to the Backport tool documentation