Expose security levels

[mhdawson]

No description provided.

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[mhdawson]

Run which tests on the different OpenSSL versions - https://ci.nodejs.org/job/node-test-commit-linux-containered/48401/

All passed, so I think that confirms it is working correctly.

In terms of testing I don't think we can change the default except at compile time, and I also think comparing against a specific version could cause problems for the shared library testing.

I can add a test that just calls the method and makes sure it is within the range documented which is currently 1-5. Does that makes sense to people?

[codecov]

Codecov Report

Attention: Patch coverage is 70.58824% with 5 lines in your changes missing coverage. Please review.

Project coverage is 89.20%. Comparing base (1238f0a) to head (5ec3b6e).
Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
src/crypto/crypto_util.cc	66.66%	2 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #56601      +/-   ##
==========================================
- Coverage   89.20%   89.20%   -0.01%     
==========================================
  Files         662      662              
  Lines      191819   191916      +97     
  Branches    36927    36941      +14     
==========================================
+ Hits       171110   171192      +82     
+ Misses      13565    13548      -17     
- Partials     7144     7176      +32     

Files with missing lines	Coverage Δ
lib/internal/crypto/util.js	93.08% <100.00%> (+0.02%)	⬆️
src/crypto/crypto_util.cc	72.01% <66.66%> (-0.46%)	⬇️

... and 52 files with indirect coverage changes

[mhdawson]

Yes, the values mean different things for different OpenSSL versions.

@richardlau what are the differences in meaning between the openssl levels ?

They all seem to say 80, 112, 128, 192 and 256 bits in terms of what the security levels map to. The default level might be different but that is what the API exposes.

[mhdawson]

Added the test since I had it ready to go.

[mhdawson]

In terms of doc Returns: {number} The [default OpenSSL security level][]. is a link to the description of the security levels.

[mhdawson]

The main question though is if it should just be private method, if that seems to be the consensus are there suggestions of where I should best add it?

[richardlau]

Yes, the values mean different things for different OpenSSL versions.

@richardlau what are the differences in meaning between the openssl levels ?

For example. compare the Level 1 description for OpenSSL 3.0:

The security level corresponds to a minimum of 80 bits of security. Any parameters offering below 80 bits of security are excluded. As a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. All export cipher suites are prohibited since they all offer less than 80 bits of security. SSL version 2 is prohibited. Any cipher suite using MD5 for the MAC is also prohibited. Note that signatures using SHA1 and MD5 are also forbidden at this level as they have less than 80 security bits.

to OpenSSL 3.4 (emphasis is added by me):

The security level corresponds to a minimum of 80 bits of security. Any parameters offering below 80 bits of security are excluded. As a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. Any cipher suite using MD5 for the MAC is also prohibited. Any cipher suites using CCM with a 64 bit authentication tag are prohibited. Note that signatures using SHA1 and MD5 are also forbidden at this level as they have less than 80 security bits. Additionally, SSLv3, TLS 1.0, TLS 1.1 and DTLS 1.0 are all disabled at this level.

OpenSSL 3.4 adds disabling SSLv3, TLS 1.0, TLS 1.1 and DTLS 1.0 at Level 1. In OpenSSL 3.0, SSLv3 is disabled at Level 2, TLS 1.0 at Level 3 and TLS 1.1 at Level 4. Also the OpenSSL 3.4 mentions "Any cipher suites using CCM with a 64 bit authentication tag are prohibited", which is not present in the description for OpenSSL 3.0.

[mhdawson]

Looks like failures were due to changes landed since I rebased yesterday.

[mhdawson]

@richardlau thanks for pointing out the specific differences. Seems odd that they would change what a security level means but some of those do seem like functional changes.

[mhdawson]

@jasnell I think I addressed your comments as well as moving the method so it is internal only.

In terms of boringssl one remaining question I had was how version numbers are reported in process.versions when boringssl is used because the existing checks:

const hasOpenSSL = (major = 0, minor = 0, patch = 0) => {
  if (!hasCrypto) return false;
  if (OPENSSL_VERSION_NUMBER === undefined) {
    const regexp = /(?<m>\d+)\.(?<n>\d+)\.(?<p>\d+)/;
    const { m, n, p } = process.versions.openssl.match(regexp).groups;
    OPENSSL_VERSION_NUMBER = opensslVersionNumber(m, n, p);
  }
  return OPENSSL_VERSION_NUMBER >= opensslVersionNumber(major, minor, patch);
};

Only seem to consider openSSL, unless process.versions still look like OpenSSL is being used even though its boringssl under the covers. Do you know how the versions are reported when boringssl is used?

[mhdawson]

@richardlau are you ok with the PR after the latest updates?

[jasnell]

@mhdawson .... I'm not sure how boringssl is represented in process.versions. This might be helpful https://github.com/search?q=repo%3Aelectron%2Felectron+%22process.versions%22+%22boringssl%22&type=code

[mhdawson]

@jasnell, it looks like that means that if BoringSSL is used then process.vesions.openssl is not defined. In that case none of the existing checks being moved over to the check against the security level should help/hurt the BoringSSL case.

[jasnell]

I would confirm that with the electron team before progressing. @codebytere

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/64586/