Consider if we should always enforce/check for FIPS compliance during TLS initialization.

[tobz]

Presently, we utilize rustls, with its default cryptography provider, AWS-LC, as a pathway to generating FIPS-compliant ADP binaries. While FIPS is not currently enabled by default, it is likely that we will want to do so in the future to avoid issues around FIPS-vs-not-FIPS builds.

However, enabling FIPS support boils down to enabling a specific set of feature flags on related crates, which is opaque and doesn't lend itself well to asserting that a build was built in FIPS mode.

We should consider what it might take to check for FIPS mode at runtime, such that we could ensure that startup terminated if we detected that we were not in FIPS mode. This would also require analyzing if always running in FIPS mode would be sufficient/harmful to users when FIPS compliance wasn't actually necessary.

[tobz]

We're actually checking (or will be checking, rather) for FIPS mode as part of #205.

That PR doesn't fully address this issue, though, around investigating if always using FIPS mode is harming use cases that don't need FIPS compliance.

[tobz]

From poking around more at this, it looks like out of the five major Datadog sites (US1, US3, US5, EU1, and AP1), all except one are compatible with using FIPS-only mode. This means that while it would clearly not be FIPS-compliant since the TLS stack at the other end is not inherently FIPS-compliant, we could use a FIPS-compliant build of ADP with them.

The odd one out is specifically missing support for the Extended Master Secret extension, which is required by FIPS 140-3. I'm reaching out internally to understand the nature of this difference in support and to see if it can be rectified.

In doing so, we could likely stand to always build in FIPS mode and avoid having to derive multiple builds for FIPS and non-FIPS, which would be an efficiency and simplicity win.