Open Jake-Gillberg opened 5 years ago
It's definitely sub-optimal to be failing because the key is too weak. Any secured linux distro will enforce the SSL DEFAULT@SECLEVEL=2
, and compromising the security of the whole system for the sake of one module seems problematic.
This appears to be a NodeJS core TLS module issue?
I think bankai's createKeys
function can probably be updated to fix this somehow? I don't really know what it would look like, but if anyone's interested in trying to contribute a fix, this is probably the place to investigate!
Looks like a fix was pre-emptively attempted in the past, but a typo led to it not working (keySize
rather than days
should have been set to 2048
).
It's better to have keys expire frequently BTW, especially in this sort of situation where they are easily regenerated by trusted applications. I'd recommend using a 90 day expiry the same as LetsEncrypt. This protects to some extent against key exfiltration by malware, bots etc. by limit the amount of time an exfiltrated key can be used maliciously.
PR incoming...
Turns out the default expiration for selfsigned, which is doing the cert generation, is 30 days, which is more secure. So in my PR I've just switched days
for keySize
, meaning days will default to 30 which I suspect was the intention of the original edit.
Actually I just noticed selfsigned
hardcodes one side of the cert to be 1024
. I am making a PR to that project to respect keySize for both keys, which we should wait for before considering this fixed.
Waiting on this: https://github.com/jfromaniello/selfsigned/pull/35
npm start
fails with below:Workaround: Changing a line in
/etc/ssl/openssl.cnf
from:CipherString = DEFAULT@SECLEVEL=2
toCipherString = DEFAULT@SECLEVEL=1
but it is probably better to just create a longer ssl key.
Versions: npm 6.11.3 node v10.16.3 debian buster openSSL 1.0.2g 1 Mar 2016