test: fixtures key/certs cause failures when openssl security level > 1

[reasonablytall]

• Version: v13.0.0-pre 5b8df5e
• Platform: Linux alexaub.svl.corp.google.com 4.19.37-2rodete1-amd64 deps: update openssl to 1.0.1j #1 SMP Debian 4.19.37-2rodete1 (2019-05-15 > 2018) x86_64 GNU/Linux
• Subsystem: test

In Debian testing, the latest openssl sets the default required security level to 2 in /etc/ssl/openssl.cnf (link). This requires (among other things, described here) that certs/keys be at least of a certain length depending on cipher.

Some of the keys under test/fixtures/ don't satisfy seclevel 2, and cause tests to fail when node's openssl reads that openssl.cnf.

Here's the output of python tools/test.py -J -p tap --logfile=test.log. 180 tests fail due to errors like ERR_SSL_EE_KEY_TOO_SMALL.

The issue can be avoided by changing the line CipherString = DEFAULT@SECLEVEL=2 to CipherString = DEFAULT@SECLEVEL=1 in /etc/ssl/openssl.cnf. However beware that this is globally reducing the required security on your machine.

I figure that this issue can be solved by regenerating the troublesome keys/certs with a greater size -- probably 2048 bits for RSA/DSA/DH and 256 for ECC. I've been looking into this, and I would be happy to take a crack at it! The changes would be similar to #3759, and I think that it would also be good to move the certs under test/fixtures/ to be under test/fixtures/keys/ and generate them in the Makefile.

[bnoordhuis]

I think at least some of the tests check that things like 1024 bits RSA still work. Your proposal would invalidate those and I don't think that's something we'll accept, you'd have to float a downstream patch for them. Everything else is fair game though.

[sam-github]

It looks like you could add SSL_CTX_get_security_level() support, and PR changes to the tests to understand whether they should pass or fail. Or even, assuming the error code was specific enough, add support to the tests to detect based on error code when failure is allowed due to the global security level test.

[bnoordhuis]

#27962 landed so I think this can be closed out now? Please reopen if I'm mistaken.

[reasonablytall]

#27962 unfortunately does not solve this issue because it only brings the test certs under a makefile -- it doesn't change their generation parameters to be secure enough. Changing those generation parameters should be simpler now with #27962, and I'm still interested in working on this issue, but I don't have a prediction for when I can.

[bnoordhuis]

No problem, I'll reopen.

[BobCochran]

I compiled 12.13.0 from source code on a fresh install of Debian 10.1 with all OS updates applied. When running make test-only I received 149 errors similar to this one:

Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
at Object.createSecureContext (_tls_common.js:131:17)
at Server.setSecureContext (_tls_wrap.js:1155:27)
at Server (_tls_wrap.js:1033:8)
at new Server (https.js:65:14)
at Object.createServer (https.js:89:10)
at serverKeepAliveTimeoutWithPipeline (/home/bobdeb101/node-v12.13.0/test/sequential/test-https-server-keep-alive-timeout.js:32:24)
at run (/home/bobdeb101/node-v12.13.0/test/sequential/test-https-server-keep-alive-timeout.js:28:11)
at processTicksAndRejections (internal/process/task_queues.js:75:11) {
library: 'SSL routines',
function: 'SSL_CTX_use_certificate',
reason: 'ee key too small',
code: 'ERR_SSL_EE_KEY_TOO_SMALL'
}

CipherString sets a SECLEVEL of 2:

$ egrep 'CipherString' /etc/ssl/openssl.cnf CipherString = DEFAULT@SECLEVEL=2

Kernel details:

4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux

If I can help resolve this, please get in touch with me. I'm a software developer, but not a node.js developer and I have no qualifications in C++ development, nor in openssl security contexts. I'm commenting mainly to document this issue occurs in Debian 10.1.

I recently compiled 12.13.0 under Ubuntu 18.04.3 LTS and did not get similar errors from 'make test-only'.

[sam-github]

node tests use old and unrecommended crypto, on purpose, they are still supported even if not recommended. Could you try with OPENSSL_CONF=/dev/null make test?

[andriy-simonov]

I have the same problem with versions 12.13.1 and 13.2.0 on Debian. OPENSSL_CONF=/dev/null make test actually allows the tests to pass. Is it a valid way to run the test, is it possible to miss any important cases with this configuration?

[bnoordhuis]

@andriy-simonov Yes, that's a valid way to test - it tests openssl in its default configuration (what 99% of all deployments probably use.)

[MylesBorins]

I'm running into this issue right now when building / testing on crostini (pixelbook). If this testing issue is widespread on mdoern versions of ubuntu (which have that security setting) should we perhaps consider changing some of the internals of what we do with make so that folks on linux can build / test without having to dig up this thread / set env vars?

[sam-github]

Could do so, but it could go awry, making things work for test, but then when people actually try it they don't work.

Fwiw, I run ubuntu 19.10, and haven't run into any issues related to this. Maybe I will when I update to 20.10, but I'm not going to update to a 1 day old OS. :-)

[bnoordhuis]

@sam-github If you mean 20.04, I upgraded yesterday and things work okay. :-)

[richardlau]

We've seen this on the CI on freshly installed Debian 10 and Fedora 34, which both set security level 2 and Node.js is picking up their openssl.cnf. I've had to put scripts in our Ansible playbooks to drop the security level back down for tests to pass.