NodeJS should not use openssl library default configuration (openssl_conf) or not read openssl.cnf at all

Version

16.10.0, 14.18.0, 12.22.6 (and older)

Platform

Microsoft Windows NT 10.0.19043.0 x64

Subsystem

crypto

What steps will reproduce the bug?

have an environment variable pointing to a file openssl.cnf:
export OPENSSL_CONF=`pwd`/openssl.cnf
put an invalid file there:

[default

try code like this (from ssh2)

var crypto = require('crypto');
var eddsaSupported = (function() {
  if (typeof crypto.sign === 'function'
      && typeof crypto.verify === 'function') {
    var key = '-----BEGIN PRIVATE KEY-----\r\nMC4CAQAwBQYDK2VwBCIEIHKj+sVa9WcD'
              + '/q2DJUJaf43Kptc8xYuUQA4bOFj9vC8T\r\n-----END PRIVATE KEY-----';
    var data = Buffer.from('a');
    var sig;
    var verified;
    try {
      sig = crypto.sign(null, data, key);
      verified = crypto.verify(null, data, key, sig);
    } catch (ex) {}
    return (Buffer.isBuffer(sig) && sig.length === 64 && verified === true);
  }

  return false;
})();

console.log(eddsaSupported)

How often does it reproduce? Is there a required condition?

always

What is the expected behavior?

Should output "true"

What do you see instead?

"false"
(true only for valid file content

[default]

)

Additional information

Well, actually I came here to suggest that NodeJS should use its "own" default section (see openssl_conf in https://www.openssl.org/docs/man1.1.1/man5/config.html). Now I would prefer that NodeJS isn't following env:OPENSSL_CONF and/or reading its target at all.

I had the default openssl.cnf from OpenSSL3 (even if NodeJS does not support it, this problem is completely unrelated).

The file contains these lines (among others):

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect

[default_sect]
#activate = 1

Now it seems, due to the environment variable (see step to reproduce above), NodeJS (or one of the libraries it uses) is reading openssl.cnf and via openssl_conf/openssl_init it tries to load a library "providers.dll" which fails because it is does not exist. Don't know what happens if it would be found. Maybe at least code in DLL Entrypoint is executed?

Failing to load "providers.dll" crypto.sign (see code snippet) failed.

According to OpenSSL documentation (https://www.openssl.org/docs/man1.1.1/man5/config.html), openssl_conf is used by the openssl utility, while other applications may (should!) use an alternative name.

So I suggest either use an application specific section name (nodejs_conf?) and be tolerant with format errors or disable reading of openssl.cnf at all. For the first, mistakes or unknown entries in openssl.cnf don't break NodeJS while it could be configured if necessary. But - can there be such need anyway?

I think it's a big problem that a rather unrelated file may break NodeJS execution (needless to mention it took me some time to figure this out...)

@danbev

@danbev what is your take on this?

@mhdawson

@mhdawson This is how it currently how it works using the environment variable OPENSSL_CONF or --openssl-config if set, and if there is an issue with the format of that file there should be an error message, something like:

$ cat out/Release/obj.target/deps/openssl/openssl2.cnf
[default
$ ./node --openssl-config=out/Release/obj.target/deps/openssl/openssl2.cnf -p 'crypto.createHash("md4")'
OPENSSL_CONF: 
openssl-config: out/Release/obj.target/deps/openssl/openssl2.cnf
OpenSSL configuration error:
808725745B7F0000:error:07000064:configuration file routines:def_load_bio:missing close square bracket:../deps/openssl/openssl/crypto/conf/conf_def.c:366:line 1

But if this is causing issues, which it obviously is and I'm sorry about that, I think we should look closer at how this is done and how it can be improved. I like the idea of using a specific section name for Node.js which I was not aware it was possible.

I think we should look closer at how this is done and how it can be improved.
+1

found this when I was searching for a fix to my npm issue.

https://stackoverflow.com/questions/70159252/npm-not-working-openssl-configuration-error-windows10x64

currently don't know enough about the OpenSSL config set up and how it relates to node or npm. Think you may be correct in your assertion that it should use it own native command since in my comp it seems to be looking for files in postgres, which I do not have installed currently. Could it have been me updating to the newest node? sry if this is off topic.

Closing this as I believe #43124 has dealt with this issue.

src,deps,build,test: add OpenSSL config appname

src,doc,test: add --openssl-shared-config option

[v14.x backport] src,deps,build,test: add OpenSSL config appname

src,doc,test: add --openssl-shared-config option

src,deps,build,test: add OpenSSL config appname

src,doc,test: add --openssl-shared-config option

src,deps,build,test: add OpenSSL config appname

Navigation Menu

Repository navigation

NodeJS should not use openssl library default configuration (openssl_conf) or not read openssl.cnf at all #40366

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

NodeJS should not use openssl library default configuration (openssl_conf) or not read openssl.cnf at all #40366

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

Activity

mhdawson commented on Oct 14, 2021

danbev commented on Oct 14, 2021

mhdawson commented on Oct 14, 2021

Felipevillajr commented on Nov 29, 2021

danbev commented on May 31, 2022

9 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions