The only way to connect to a database that doesn’t use one of the common certificates (e.g. any RDS Postgres database) is by disabling SSL verification. That is even what the team suggests to unaware users.
This implies that anyone on e.g. the same wifi as a running n8n instance can steal credentials to the database. This is ridiculously insecure.
There’s two issues at play here:
Nobody seems aware that this is an issue. The team suggests this. Users of this product don’t know what SSL is. They have no idea of the security hazards of checking this box.
=> This should be fixed by replacing the “Ignore SSL Issues” text within n8n’s configuration parameters by “Ignore SSL Issues (insecure)”, (or “insecure connection”) so that at least people who care about not leaking their database credentials are told that checking this leaks them. I opened pull request (security) Let users know that skipping SSL validation is insecure by Ten0 · Pull Request #11935 · n8n-io/n8n · GitHub for this.
The options to set the CA SSL certificate and client certificate and key are not available, so the only option available to people who want to connect is to check this.
=> The fix is just to be able to specify certificates.
This allows users to add their own certificates to their self hosted n8n instances. This solves part of the problem but you are right users should be aware of the risks that come with ignoring certificate errors although by ignoring the certificate it is not leaking the credential so the wording would need to be correct.
Should I also open a PR so that it says “consider configuring n8n to use your own certificate authority” instead of “consider using the Ignore SSL issues” here then?
As there are multiple parts and options we would need to come up with better wording for that error.
However “consider using” is potentially a valid use it is all about finding the right balance, as an example if the services are running on the same machine and using a self signed certificate there is very little harm in ignoring the ssl verification.
If however you were connecting to a service over the internet that for some reason isn’t configured correctly or we don’t trust the CA for it then it would be different and that is when you would likely want to add the cert.
We have since releasing that new option stopped adding the ignore option to nodes that don’t have it but we do know we need to work on other ways to allow users to configure certs as well as you may not always be able to configure the container or understand how to create certificates.
At the moment the insecure label in your PR and maybe more documentation tweaks is probably the best way to start.