Repository navigation
openssl + fips #364
Description
So AFAICT we still have no timeline on when openSSL 1.1.0 will have a validated fips module
Based on the release documents we have until December 2019 before we have to deprecate the 1.0.2 release, the version we support in 6.x and 8.x.
The latest communication from the project seems to imply that they are still only breaking ground on a technical roadmap towards validation.
The boringSSL project is currently 1.1.0 compliant afaict and has a verified fips module
That being said, the readme clearly states.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
So moving to BoringSSL is obviously not an option. That being said I'm curious what other options we have.
/cc @nodejs/crypto @nodejs/security-wg
Activity
MylesBorins commentedon Oct 19, 2017
We are finding a time next week to discuss this. If anyone wants to be involved please lmk
mhdawson commentedon Oct 26, 2017
I'd like to be involved.
jasnell commentedon Oct 26, 2017
Please include me. Once I get through updating the node_crypto internals to use internal/error, I'm planning on a bit of restructuring of the node_crypto native code to make it easier to maintain. That will likely directly impact on at least some of this work
rvagg commentedon Nov 1, 2017
Assigning this to me -- plan is to write up the various topics and submit them as proposals that we can iterate on. That'd be things like:
And maybe more. It can be both a place where we decide and document policy and also a resource that we can point users to when they have questions about these things.
rvagg commentedon Nov 1, 2017
Also info about using a shared openssl vs what we bundle, would be worth documenting why we prefer to bundle and what the issues are if you use shared (like from a Linux distro).
And, this 1.0.2m release makes me think perhaps we should document the process around our releases when they release new versions, it's become a very stable and repeatable over the past 2 years and could be easily documented as distinct from standard security releases.
rvagg commentedon Nov 2, 2017
Being told that we should also look at mbedtls to come up with an assessment of whether it could ever be something we can support as an alternative.
chrislea commentedon Nov 2, 2017
FWIW, here's the mbedtls website.
bnoordhuis commentedon Nov 3, 2017
I can answer that: no. I'll spare you the details but it's not remotely close to feature parity with openssl.
jasnell commentedon Feb 17, 2018
This discussion appears to have stalled. Is there a next step or can we close this?
ChALkeR commentedon Feb 18, 2018
Sigh… FIPS is harmful and it's sad that we need to spend time/resources because of it. I understand why we would want to keep support for it, though.
BoringSSL is not an option not only because of compat, but also because it doesn't give any API/ABI stability guarantees. The same probably affects support/backporting — there might be none.
jasnell commentedon Feb 18, 2018
This makes me wonder if we shouldn't invest some effort into a stable N-API ABI stability layer that covers the openssl API surface area. Yes, it would be a pain in the ass to make sure it keeps up to date but it would shield us from these kinds of problems in the future.
mhdawson commentedon Feb 19, 2018
@rvagg is the champion for the strategic initiative to figure this out so I'm not sure we need this issue anymore.
rvagg commentedon Feb 22, 2018
yep, moved to #479 for now
doc: update link to PR for OpenSSL Policy (#696)