Repository navigation
NodeJS should not use openssl library default configuration (openssl_conf) or not read openssl.cnf at all #40366
Description
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...)
Activity
mhdawson commentedon Oct 14, 2021
@danbev what is your take on this?
danbev commentedon Oct 14, 2021
@mhdawson This is how it currently how it works using the environment variable
OPENSSL_CONFor--openssl-configif set, and if there is an issue with the format of that file there should be an error message, something like: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.
mhdawson commentedon Oct 14, 2021
Felipevillajr commentedon Nov 29, 2021
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.
danbev commentedon May 31, 2022
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
9 remaining items
[v14.x backport] src,deps,build,test: add OpenSSL config appname
src,doc,test: add --openssl-shared-config option
src,doc,test: add --openssl-shared-config option
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