Initial implementation of opensl FIPS baseline process#357
Initial implementation of opensl FIPS baseline process#357ColtonWilley wants to merge 2 commits intowolfSSL:masterfrom
Conversation
docs/FIPS_INTEGRATION_GUIDE.md
Outdated
| | Restriction | Requirement | | ||
| |-------------|-------------| | ||
| | RSA Key Size | 2048 bits minimum | | ||
| | SHA1 Signing | Blocked (verification allowed) | |
There was a problem hiding this comment.
SHA1 hashing is still enabled right? May want to clarify that
docs/FIPS_INTEGRATION_GUIDE.md
Outdated
| ## Replace Default Mode (Recommended for FIPS) | ||
|
|
||
| FIPS certification applies system-wide, meaning all cryptographic operations should use the FIPS-validated module. wolfProvider's replace-default mode ensures this by making wolfProvider the primary cryptographic provider for all OpenSSL operations. In this model it is impossible for an application | ||
| to use the default provider, any attempts to do so will yield wolfProvider instead. |
There was a problem hiding this comment.
Nit: unexpected line break here
| > | ||
| > A thorough code review is recommended to ensure all cryptographic operations route through OpenSSL's provider interface. | ||
|
|
||
| ### Common Failures |
There was a problem hiding this comment.
Consider moving Common Failures section right below Run Your Tests
|
|
||
| ### Run Your Tests | ||
|
|
||
| Run your application's test suite against the baseline build. Fix any failures before proceeding. |
There was a problem hiding this comment.
Any more guidance on how to fix? Alternatively, maybe suggest they reach out to support@wolfssl for consulting?
|
|
||
| --- | ||
|
|
||
| ### Option B: Manual Build (Autotools) |
There was a problem hiding this comment.
Is there a corresponding Option A?
docs/FIPS_INTEGRATION_GUIDE.md
Outdated
|
|
||
| Choose the approach that fits your workflow. | ||
|
|
||
| ### Build Script |
There was a problem hiding this comment.
We should point out that the build script is the recommended path
docs/FIPS_INTEGRATION_GUIDE.md
Outdated
|
|
||
| ### Patch OpenSSL | ||
|
|
||
| Apply FIPS baseline restrictions to your OpenSSL source tree. See [FIPS Baseline Patches](../patches/openssl-fips-baseline/README.md) for detailed options and common errors. |
There was a problem hiding this comment.
Could clarify this a bit, Eg. "This mode disables non-FIPS approved algorithms so one can evaluate their application before integrating wolfProvider".
| ``` | ||
|
|
||
| --- | ||
|
|
There was a problem hiding this comment.
Consider adding notes about confirming the install, or running the unit and cmd line tests.
| FIPS_VERSION="unknown" | ||
|
|
||
| # Check if provider output indicates FIPS mode | ||
| if ${OPENSSL_BIN} list -providers 2>/dev/null | grep -qi "fips"; then |
There was a problem hiding this comment.
Should we specifically check for "Baseline" here?
| /* Step 3: Create library contexts for each provider */ | ||
| TEST_INFO("Step 3: Creating library contexts for each provider..."); | ||
|
|
||
| g_default_libctx = OSSL_LIB_CTX_new(); |
There was a problem hiding this comment.
Consider following naming convention from test/unit.c, eg: wpLibCtx and osslLibCtx
| } | ||
| TEST_INFO(" ✓ Default provider library context created"); | ||
|
|
||
| g_wolfprov_libctx = OSSL_LIB_CTX_new(); |
There was a problem hiding this comment.
I'm confused. Why load wolfprovider in this test? Isn't the whole point to prove OSSL behavior without wolfprov?
If we want to confirm that ossl fips baseline behaves same as wolfprov fips, recommend adding an option to the test executable to select which one to test.
There was a problem hiding this comment.
Its tricky. For the user I do want them to baseline with this modified openssl with no wolfprovider at all. These tests are not really designed for the external user, they assume that the baseline behavior is functional. These are internal tests for us to use to validate the baseline behavior. I think if we start mixing and matching customers will get confused.
There was a problem hiding this comment.
Understood, but the point remains. Why test something different than what the customer will use?
There was a problem hiding this comment.
No, this is testing to validate that the patches themselves function properly. We have the inverse requirement we normally have, normally openssl is correct and we match their behavior, now wolfprovider is the source of truth and we are testing that our patches are correct and yield equivalent behavior.
There was a problem hiding this comment.
Its would also make for a very long and confusing flow, as the baseline testing cant be run with replace default. So they would need to build without replace default to verify patches, and then clean everything and build a differently patched openssl and wolfprovider with replace default this time.
There was a problem hiding this comment.
libwolfprov is already built or available with this flow iiuc. I'm not suggesting we test against replace default
There was a problem hiding this comment.
I'm only suggesting running this test twice, with only one provider loaded at a time. Having both loaded seems like a risk of winding up at the wrong one (albeit a small risk)
There was a problem hiding this comment.
Oh I see what you are saying. We could do the baseline with a single provider and then do it with replace default as the ground truth?
There was a problem hiding this comment.
Exactly, just for extra peace of mind
| return TEST_SUCCESS; | ||
| #endif | ||
|
|
||
| /* Test 1: MD5 should be unavailable in FIPS mode */ |
There was a problem hiding this comment.
IIUC, the test mostly checks that functionality is disabled/removed. Consider adding a sanity check that a basic FIPS operation does work.
Add OpenSSL FIPS baseline testing infrastructure