Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Initial implementation of opensl FIPS baseline process#357

Open
ColtonWilley wants to merge 2 commits intowolfSSL:masterfrom
ColtonWilley:wp_openssl_fips_baseline
Open

Initial implementation of opensl FIPS baseline process#357
ColtonWilley wants to merge 2 commits intowolfSSL:masterfrom
ColtonWilley:wp_openssl_fips_baseline

Conversation

@ColtonWilley
Copy link
Contributor

Add OpenSSL FIPS baseline testing infrastructure

  • OpenSSL patches to enforce FIPS restrictions
  • Standalone test suite verifying wolfProvider matches baseline behavior
  • Scripts for patching OpenSSL
  • Documentation overhaul new integration guides

| Restriction | Requirement |
|-------------|-------------|
| RSA Key Size | 2048 bits minimum |
| SHA1 Signing | Blocked (verification allowed) |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHA1 hashing is still enabled right? May want to clarify that

## 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: unexpected line break here

>
> A thorough code review is recommended to ensure all cryptographic operations route through OpenSSL's provider interface.

### Common Failures
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any more guidance on how to fix? Alternatively, maybe suggest they reach out to support@wolfssl for consulting?


---

### Option B: Manual Build (Autotools)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a corresponding Option A?


Choose the approach that fits your workflow.

### Build Script
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should point out that the build script is the recommended path


### 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could clarify this a bit, Eg. "This mode disables non-FIPS approved algorithms so one can evaluate their application before integrating wolfProvider".

```

---

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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();
Copy link
Contributor

@padelsbach padelsbach Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood, but the point remains. Why test something different than what the customer will use?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libwolfprov is already built or available with this flow iiuc. I'm not suggesting we test against replace default

Copy link
Contributor

@padelsbach padelsbach Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, just for extra peace of mind

return TEST_SUCCESS;
#endif

/* Test 1: MD5 should be unavailable in FIPS mode */
Copy link
Contributor

@padelsbach padelsbach Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, the test mostly checks that functionality is disabled/removed. Consider adding a sanity check that a basic FIPS operation does work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants