Random anecdotes
Opened this issue · 1 comments
mendel
27 days ago
made a change today to only permit FIPS ciphers in STARTTLS on our mail servers. the senders that are having trouble are all US government :facehoof:
reaperhulk
[10 months ago]
If you need FIPS compliance there are quite a few things to watch out for...
OpenSSL has a bunch of forms of FIPS. There's the legacy FIPS canister from 1.0.x, there's the RHEL style FIPS patches, and there's the new OpenSSL 3.0 FIPS provider. Each one behaves differently with regard to how to enable it, whether it allows non-FIPS algorithms in FIPS mode, etc.
For example, enabling FIPS in RHEL8 requires following section 9.1 in the security policy for this CMVP certificate (https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4271), which notes that the kernel must be booted with fips=1 as an arg or else it is not compliant (despite potentially appearing to be so).
Once you've verified that you have correctly enabled it (shockingly hard especially at scale) and you're using FIPS only algorithms (which some of these enforce and others do not), then you've got even more nonsense. For example, what if you need BGP with MD5? Well, that's not FIPS, but it turns out you may have to do it anyway. So now you've got to figure out a way to run FIPS and non-FIPS alongside each other. Or perhaps you're using AES GCM. FIPS compliant right? Well, FIPS has very weird requirements for nonce generation that include generation inside the FIPS boundary so simply generating 12 random bytes with your FIPS CSPRNG is arguably insufficient.
I could go on for a long time here, but honestly any organization that starts needing FIPS will learn these lessons via painful interactions with auditors and their own engineering teams screaming at them. But remember, scrypt is FIPS compliant because its final step is PBKDF2 :cool-cat: