-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Update boringcrypto to enable TLS 1.3 without CHACHA stream ciphers in FIPS builds #31746
Comments
FIPS compliant Envoy required TLS 1.2 as the maximum version. Currently TLS 1.3 in Envoy FIPS mode allows using chacha20 ciphersuite because Envoy does not prevent boringcrypto from selecting it. I tested it as follows:
|
cc @ggreenway |
I got some clarification on the situation from @agl. There is no requirement to support TLS 1.3 in FIPS-140 in general, which is understood to be a certification program for crypto modules via https://csrc.nist.gov/projects/cryptographic-module-validation-program. The policy to support TLS 1.3 applies to government agencies, separately from FIPS-140. Additionally, FIPS-140 only affects boringssl-crypto and not the TLS stack. We are allowed to patch TLS stack and remove ChaCha20-Poly1305 ciphersuite from boringssl in FIPS mode when using TLS 1.3. |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
FYI the updated BoringCrypto FIPS module has now been published: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4735 |
I started the work to upgrade, but I'm hitting a test failure in the BoringSSL tests. See #35534. |
Copy over my comment on the PR #35534 here: @ggreenway @kyessenov I think the certs in that particular test (e.g. https://github.com/google/boringssl/blob/0c6f40132b828e92ba365c6b7680e32820c63fa7/ssl/ssl_test.cc#L8014 are "expired" ("Not After" 2022-12-06). Probably the following options are viable:
but yeah both options require patching the boringssl source (but only on test). |
I think we need https://github.com/google/boringssl/blob/ec09a2dad2781e35bdb2a3b873ff395b4376e444/ssl/ssl_lib.cc#L3421 (SSL_CTX_set_compliance_policy) to be settable as well ? |
I have attempted a PR (#36649) that uses "options" to set the policy. It's incomplete and just a draft to see what direction to take for setting compliance policy. Please review it, the idea is to set the boringssl compliance policy for fips compliant. |
FIPS requirements require support of TLS 1.3 as of Jan 1st 2024, and current boringcrypto version and lack of cipher deactivation prevent its use in envoy FIPS builds
go has decided in 1.21.6 to migrate to the candidate FIPS version of boringcrypto and enable TLS 1.3, as FIPS regulation mandates TLS 1.3 as of Jan 1st 2024
In order to be compliant and use TLS 1.3, we’d need this version of boringcrypto and its ability to deactivate CHACHA cipher in TLS 1.3 bound in envoy to use it (either using the new policy context or explicitly setting ciphers)
Go took the stance that support of TLS 1.3 takes precedence over certification of this boringcrypto version.
Is the position of envoy maintainers the same or to wait for the cerfication? Or will it wait for the certificate prior to progress on this?
The text was updated successfully, but these errors were encountered: