Node uses an hardcoded list of certificate authorities

[fir4]

I was dumbfounded when I realized that Node uses a statically compiled, manually updated, hardcoded list of certificate authorities, rather than relying on the system's trust store, or even just a directory truststore of its own.

This causes a large amount of problems :

• Dependancy on the Node community for reactiveness in addition or removal of certificates
• Dependancy on the Node community in terms of certificate trust
• Prevents companies and anyone with their own PKI from using their certificates globally
• Requires support from EVERY node application making use of SSL to include certificates
• Requires modification of source code if an application doesn't happen to support it
• Requires modification and rebuilding of Node to remove certificates that wouldn't be trusted by an organisation

Now, I can see no practical use for that. While this is acceptable in a development environment, where you can make changes to your own application, this is outright unusable... and i can't stress enough the security implications for many organisations.

Proposed solutions :

• Make use of the standard system trust store, like any sensible application
• Use a dedicated globally installed trust store, allowing user modifications, and why not, handling with npm
• Dynamically load CAs using relative path, in a way similar to the usage of the node_modules folder

TL;DR: CA Certificates are hardcoded in node. It may be OK for dev, but it sucks big time for ops.

[kapouer]

Indeed, a distribution like debian needs to work around that using that kind of patch.

I already asked this in
#3159
I suppose a pull request could make it now ? @fir4 feels like writing one ?

[doodadjs]

@kapouer Path should not be hard-coded. Also what for other distributions of Linux, and other OSs like Windows and OS X ? This issue requires more research

[kapouer]

I think the simplest thing to do is to have a configurable path as a build option - so that each distributor can point nodejs to the right place where it can find the system-installed root ca(s).
I don't think it's worth the time spent to be able to change that path at runtime.

[fir4]

Yeah, those were simple ideas, in case you'd want more flexibility. Using a configurable path on ./configure step would be a great start, however I have literally zero idea how Certificates are handled on MacOS and Windows...

[doodadjs]

For Windows it's too complicated. It's not just a folder. I'm thinking of a solution... Have a download link to an automatically generated zip file with the CAs. Bundle the current version with each distribution of nodejs. Add an environment variable to nodejs to locate the CAs folder. The installer will extract CAs to a proper location and set the environment variable. For Unix-like systems, the installer may try to locate system CAs. If no installer, this will have to be done manually.

EDIT: By default, use a build option like kapouer mentionned.

[royallabs]

+1

[cpmsmith]

👍

Absolutely +1

Using the systems certificates store would of cause be best.
But even that should be configurable.

A configuration option like the one used by npm (setting a caFile) would be of great help for me and presumably for most others running into problems with ca-certs.

This could be a global configuration option, an environment variable and/or a commandline param.
It should not be a compile option in my opinion - at least not without being overwriteable afterwards.

While this is acceptable in a development environment…

It may be acceptable in most development environments.
Anyhow it is absolutely not acceptable by any means in my development environment nor in some others.

We are working behind a corporate proxy with ssl scanning.
Meaning the secure connection does not exist between our machines and the internet servers but between our machines and a trusted proxy and another between that proxy and the internet servers.

This leads to absolutely unexpected behavior, for example when installing packages using npm.

While we can configure npm to accept our certificate we can not make the postinstall scripts do the same. This leads to many packages not being able to be installed properly.

This means we can not even npm install some simple grunt tasks although npm already has the option to change the trusted CAs.

[ijstokes]

This is a major issue for commercial deployment of nodejs and a major obstacle to our node based software being adopted by large organizations that have their own in-house PKI. It is also indicative of a problem with the node developers lack of understanding of the importance of doing security "right".

I am very interested in seeing this issue get resolved and if there are sensible ways I can contribute to its resolution, please someone from the NodeJS team let me know (yes, a PR, I realize, but if there is any guidance on how to put that together or other considerations/constraints...)

[bnoordhuis]

It is also indicative of a problem with the node developers lack of understanding of the importance of doing security "right".

Please.

yes, a PR, I realize, but if there is any guidance on how to put that together or other considerations/constraints...

Start with reading CONTRIBUTING.md. If you still have questions afterwards, I can probably answer them.

[bkreider]

Please.

Please as in, "please fix this" or "please, it is a super good idea to hard code the list of certificate authorities? "

this is outright unusable... and i can't stress enough the security implications for many organisations.

+1.

[Fishrock123]

Please as in, "please fix this" or "please, it is a super good idea to hard code the list of certificate authorities? "

I Think that was a "Please do not assume things".

Please as in, "please fix this" or "please, it is a super good idea to hard code the list of certificate authorities? "

I think its more sort of "please stop being that accusing".

It is also indicative of a problem with the node developers lack of understanding of the importance of doing security "right".

I do not think they do not understand the importance to do it right.
One major problem of security is, that most people do not know, how to do it right and do not see all the problems which may arise. This is btw. a major problem in software engineering in general.

As long as no authoritys certs need to be removed, nobody outside of corporate environments with high security and compliance standards may even notice any problems with the integration as it is today. And nobody outside such environments would even think about all the problems wich will arise inside this environments.

This seems pretty much normal to me and there is no point in being harsh, accusing the developers not to try to do things right or anything alike.

Anyways, in my opinion the issue is of great importance and it needs to be fixed asap.