[
https://issues.apache.org/jira/browse/QPID-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Partha Sarathy Maripini updated QPID-8773:
------------------------------------------
Description:
*Motivation:*
Deploying Apache Qpid Broker-J in enterprise and regulated environments (such
as govcloud) requires FIPS 140 compliance. Broker-J's only direct use of Bouncy
Castle in the broker runtime is building the self-signed certificate. Because
that code is in broker-core:
1. Every deployment carries the standard Bouncy Castle libraries
(bcprov-jdk18on / bcpkix-jdk18on), which are not FIPS 140 certified;
2. The static BouncyCastleProvider in SSLUtil conflicts with a runtime that
supplies its own Bouncy Castle libraries on the platform class loader.
*Proposed Solution:*
1. Move self-signed certificate generation behind a small SPI in broker-core
(CertificateGeneratorFactory / CertificateGenerator, discovered with
QpidServiceLoader). broker-core then has no Bouncy Castle dependency, and an
enforcer rule keeps it that way.
2. Move the existing Bouncy Castle code into a new plugin,
qpid-broker-plugins-certificate-generator-bouncycastle, which the standard
distribution includes. The plugin does not create or register a security
provider: keys, signatures and certificate parsing use default JCA provider
selection, so a FIPS provider preferred by the platform is used automatically.
3. Select the generator when the Broker starts. If one generator is installed
it is used; if several are installed, the system property
qpid.security.certificateGenerator selects one. An unknown type, or a generator
that cannot be created, makes startup fail.
4. Deployments that must not use Bouncy Castle can leave the plugin out
(keystores whose certificate is already stored still load) or install a
different generator through the same SPI.
*Impact:*
No change for the standard distribution. Applications that embed
qpid-broker-core directly must add the plugin and the Bouncy Castle libraries
(bcprov, bcpkix, bcutil) to keep creating AutoGeneratedSelfSigned keystores.
*Out of scope:*
Other FIPS-related areas, such as BCFKS / PKCS12-PBMAC1 keystores or TLS
through BCJSSE, can follow as separate issues if needed.
*Note:* I am actively working on this change and will submit a Pull Request
shortly.
was:
*Motivation:*
Deploying Apache Qpid Broker-J in enterprise and regulated environments (such
as govcloud) requires strict FIPS 140 compliance. Currently, Broker-J relies on
standard Bouncy Castle libraries (bc-prov / bcprov-jdk18on), which are not FIPS
140 certified.
*Proposed Solution:*
1. Provide support for registering the Bouncy Castle FIPS provider
(org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider) dynamically in
[SSLUtil.java|https://github.com/apache/qpid-broker-j/blob/49098be941a6e6c5c5fc17759c30e0e1e0331c80/broker-core/src/main/java/org/apache/qpid/server/transport/network/security/ssl/SSLUtil.java#L117]
and related TLS security modules.
2. Introduce a configuration property (e.g.,
qpid.security.tls.enableFIPSMode=true) to enable FIPS provider registration
when configured.
3. Allow substituting standard bc-prov dependencies with bc-fips at
build/deploy time.
*Impact:*
This enables Qpid Broker-J to run in FIPS-validated environments while leaving
default functionality unchanged for existing standard deployments.
*Note:* I am actively working on this change and will submit a Pull Request
shortly.
Summary: Decouple self-signed certificate generation from Bouncy Castle
to support FIPS 140 deployments (was: Support for FIPS 140 compliance using
Bouncy Castle FIPS (bc-fips))
> Decouple self-signed certificate generation from Bouncy Castle to support
> FIPS 140 deployments
> ----------------------------------------------------------------------------------------------
>
> Key: QPID-8773
> URL: https://issues.apache.org/jira/browse/QPID-8773
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Partha Sarathy Maripini
> Priority: Major
> Labels: FIPS, Security
>
> *Motivation:*
> Deploying Apache Qpid Broker-J in enterprise and regulated environments (such
> as govcloud) requires FIPS 140 compliance. Broker-J's only direct use of
> Bouncy Castle in the broker runtime is building the self-signed certificate.
> Because that code is in broker-core:
> 1. Every deployment carries the standard Bouncy Castle libraries
> (bcprov-jdk18on / bcpkix-jdk18on), which are not FIPS 140 certified;
> 2. The static BouncyCastleProvider in SSLUtil conflicts with a runtime that
> supplies its own Bouncy Castle libraries on the platform class loader.
> *Proposed Solution:*
> 1. Move self-signed certificate generation behind a small SPI in broker-core
> (CertificateGeneratorFactory / CertificateGenerator, discovered with
> QpidServiceLoader). broker-core then has no Bouncy Castle dependency, and an
> enforcer rule keeps it that way.
> 2. Move the existing Bouncy Castle code into a new plugin,
> qpid-broker-plugins-certificate-generator-bouncycastle, which the standard
> distribution includes. The plugin does not create or register a security
> provider: keys, signatures and certificate parsing use default JCA provider
> selection, so a FIPS provider preferred by the platform is used automatically.
> 3. Select the generator when the Broker starts. If one generator is installed
> it is used; if several are installed, the system property
> qpid.security.certificateGenerator selects one. An unknown type, or a
> generator that cannot be created, makes startup fail.
> 4. Deployments that must not use Bouncy Castle can leave the plugin out
> (keystores whose certificate is already stored still load) or install a
> different generator through the same SPI.
> *Impact:*
> No change for the standard distribution. Applications that embed
> qpid-broker-core directly must add the plugin and the Bouncy Castle libraries
> (bcprov, bcpkix, bcutil) to keep creating AutoGeneratedSelfSigned keystores.
> *Out of scope:*
> Other FIPS-related areas, such as BCFKS / PKCS12-PBMAC1 keystores or TLS
> through BCJSSE, can follow as separate issues if needed.
> *Note:* I am actively working on this change and will submit a Pull Request
> shortly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
