openssl + fips

[MylesBorins]

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

[MylesBorins]

We are finding a time next week to discuss this. If anyone wants to be involved please lmk

[mhdawson]

I'd like to be involved.

[jasnell]

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]

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:

• Our relationship to OpenSSL and the LTS happenings over there and how we're dealing with 1.0.2 EOL
• Our position on LibreSSL (my proposal will be "we'll support it in our codebase if someone wants to PR a complete patch and we may consider adding support in our test infra after that". I've had a few private discussions about the work I started on that and we may see a PR soon based on that)
• Our position on BoringSSL (likely going to be "not supported" but we could discuss maybe matching the stance we take on LibreSSL)
• Information about FIPS support that we can point users to (might just have to be "only FIPS in Node 4 -> 8 until we get it upstream, will need to investigate)
• Information about TLS 1.3 we can point users to (I don't know if it's been finalised but I believe OpenSSL 1.1 should have complete support, will need to investigate)

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]

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]

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]

FWIW, here's the mbedtls website.

[bnoordhuis]

I can answer that: no. I'll spare you the details but it's not remotely close to feature parity with openssl.

[jasnell]

This discussion appears to have stalled. Is there a next step or can we close this?

[ChALkeR]

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]

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]

@rvagg is the champion for the strategic initiative to figure this out so I'm not sure we need this issue anymore.

[rvagg]

yep, moved to #479 for now