fips: Add Compliance policy and set it in SSL context

[pchan]

trafficstars

Commit Message: Add Compliance policy and set it in SSL_CTX Additional Description: This is an attempt to introduce compliance policy in envoy, in congruence with policy in boringssl (see https://boringssl.googlesource.com/boringssl/+/451ea3ca3e0b61273333162564f16d190f6b6d14) We set fips ssl_compliance_policy_fips_202205 which sets fips 140-3 that allows use of TLS 1.3 (with allowed ciphers).

Risk Level: low. Testing: n/a. Docs Changes: n/a. Release Notes: n/a. Platform Specific Features: n/a.

This PR is a draft/WIP that attempts to fix #31746 , and is intended to create a mechanism to specify compliance policy and set fips 140-3 in Envoy.

cc: @howardjohn @ggreenway

[repokitteh-read-only[bot]]

Hi @pchan, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

:cat:

Caused by: https://github.com/envoyproxy/envoy/pull/36649 was opened by pchan.

see: more, trace.

[tyxia]

@pchan PTAL at CI failures which seem legit.

Also you can convert this PR to draft if it is not ready.

/wait

[dio]

It seems like ssl_compliance_policy_fips_202205 is not included in https://boringssl.googlesource.com/boringssl.git/+/refs/tags/fips-20220613?

[pchan]

It seems like ssl_compliance_policy_fips_202205 is not included in https://boringssl.googlesource.com/boringssl.git/+/refs/tags/fips-20220613?

Yes, @ggreenway The certificate validated module (fips-20220613) does not have the patch that allows setting compliance policy. I see subsequent fips branches (fips-20230428, fips-20240407, fips-20240805) in boringssl which has back-ported the compliance policy change. Can we update to the later boringssl fips branches without invalidating the module ? It looks like we can't [1], also fips modules do some sort of self-test where they check for code/data at power-on which may fail. What should be the next course of action ?

[1]

The set of files specified in the archive constitutes the complete set of source files of the validated module. There shall be no additions, deletions, or alterations of this set as used during module build.

[ggreenway]

If the change isn't in the current FIPS version of boringssl, I don't know what the path forward is. We may need to wait for the next FIPS validated version of boringssl (in roughly a year, based on previous release cadence).

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[github-actions[bot]]

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[stanpalatnik]

Can we keep this open until the next boringssl release is available?

[ggreenway]

It's probably going to be a year; let's keep the issue open, and leave this closed as it isn't actionable any time soon.

[keithmattix]

Succeeded by #39056