Issue #12428 - ALPN Processor for Bouncy Castle FIPS

[lucarota]

Ciao,

I added a new ALPNProcessor for Bouncy Castle TLS FIPS version, both client and server, based on the JDK9ServerALPNProcessor that resolves the issue #12428.
Now all the tests should be correct.

Regards,
Luca Rota

[sbordet]

@lucarota my understanding is that the API used are those of the JDK, so the configuration of BouncyCastle FIPS is orthogonal.

What I mean is that I would prefer this PR to have dependencies on bctls rather than anything FIPS, since whether one wants to use FIPS or not is just matter of external configuration.
Please correct me if I am wrong.
Is there a specific reason you used FIPS?

BC FIPS code also does not appear to be in a public repository (I could not find it), so I'd stick with what's in GitHub.

@lachlan-roberts, on top of this PR we should refresh jetty-keystore which is still using the old jdk15to18 jars.

@jmcc0nn3ll I assume there is no problem with the BouncyCastle license? It is a MIT license, and we should have already cleared it for jetty-keystore, but I would like to be sure, as this PR would make use of BouncyCastle for Jetty's TLS, rather than just use BouncyCastle in the jetty-keystore tool to generate a KeyStore on-the-fly.

[joakime]

@jmcc0nn3ll I assume there is no problem with the BouncyCastle license? It is a MIT license, and we should have already cleared it for jetty-keystore, but I would like to be sure, as this PR would make use of BouncyCastle for Jetty's TLS, rather than just use BouncyCastle in the jetty-keystore tool to generate a KeyStore on-the-fly.

We would need to put the license block for BouncyCastle into the jetty-keystore.mod file, and have users accept it. (like all other non-eclipse licensed modules we have now)

[jmcc0nn3ll]

@gregw @joakime It should be run through the eclipse IP process and go from there, if it can be included then we are golden, if not then we'll have to do the agreement thing.

[lucarota]

Ciao @sbordet,

sorrry but the FIPS and non-FIPS versions of BouncyCastle aren’t compatible with each other.

The reason we went with the FIPS version here is to ensure compliance with federal standards. This is not just about preference it’s a requirement for certain environments.

If you’d rather avoid tying this PR to FIPS-specific dependencies, we can definitely talk about other options. But for now, FIPS was chosen to meet our compliance needs.

BC FIPS code also does not appear to be in a public repository (I could not find it), so I'd stick with what's in GitHub.

You're right, the BC FIPS source isn’t on GitHub, but it’s on Maven central or, as stated on README of the BC repository, you can request it from BouncyCastle by email.

Let me know if that makes sense.

Ciao,
Luca

[sbordet]

@lucarota

sorrry but the FIPS and non-FIPS versions of BouncyCastle aren’t compatible with each other.

In what sense?

What FIPS APIs do you use in this PR that are not available in non-FIPS?

Actually, unless I missed something, you are not even using BC APIs, but just the JDK APIs.

If that's the case, then you can externally configure the providers, and you can choose FIPS or non-FIPS as you like, and everything will work anyway.

To be clear:

• BouncyCastleServerALPNProcessor does not depend on BC.
• BouncyCastleClientALPNProcessor only depends on BC due to init(), but init() is just there to simplify things and could be implemented empty (or not even overridden).

Given the above, it is left to the test setup, or application setup, to install the BC providers externally.
Once they are installed, the BC ALPNProcessors will work.

Am I missing something?

[lucarota]

Ciao Simone,

Oh OK now I see what you mean.
By eliminating the init() method I can remove the bouncy castle dependency completely. It remains only for testing, but then using the non-FIPS version is no problem.

I have modified the code accordingly.

Regards,
Luca