You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add FIPS test and example application with HTTP.
The check is simply executing OpenSSL.fips_mode which returns bool.
Based on exit status we can then know whether it failed/succeeded as we
expect it to.
The app has 4 GET endpoints that executes some OpenSSL capability.
2 of those test symmetric ciphers:
* '/symmetric/aes-256-cbc' -- succeeds under FIPS
* '/symmetric/des-ede-cbc' -- fails under FIPS
2 of those test digests:
* '/hash/sha256' -- succeeds under FIPS
* '/hash/md5' -- fails under FIPS
The app is prepared so that it tests assumptions of when should what
fail, under both FIPS and non-fips environment.
These endpoints either return 200 if the case for them succeeded
or 5xx for FIPS related failures and 4xx for general failures not
accounted for. When a failure happens when it shouldn't, the app also
returns backtrace in the response body.
A few examples:
MD5 succeeds and FIPS is enabled, that's unexpected, returns 500
SHA256 fails in any case, 418 is returned because that shouldn't happen
with both FIPS disabled and enabled, something else went wrong.
MD5 fails with FIPS enabled, that's desired and expected, returns 200.
Since more information is passed within body on response,
`curl --fail-with-body` is recommended.
409 is chosen to differentiate 500 returned in cases we
might expect. It was chosen firstly as it is "user error", either the code is
wrong, or the setup is wrong.
For the purpose of building and running the app,
and adjustment was made to run_test_application to be able to run a custom
named container.
Otherwise there is only testapp to be ran and we can have better names.
0 commit comments