Fallback to non-SSL connection #2720
Comments
Not ruling out support, but: if you don’t care about TLS, don’t turn it on. If it’s a connection where it makes sense to have TLS, don’t be vulnerable to MITM to save one environment variable that distinguishes production from development or whatever the case may be. |
There's a use case for connecting to a server where you don't know whether it's listening on TLS or not, as evidenced by libpq's support for this use case. In those cases, you often don't care about verifying the cert because you were happy to connect without TLS anyway. This can be a OK if the connection is secured at a different layer. E.g. someone gives you a secure tunnel to their DB along with connection info, but neglected to specify if they're using TLS. This is pretty common, since people know to provide hostname, port, username, password, DB name, etc but often forget about ssl mode and certs. Or they, rightly or wrongly, just don't want to worry about certs since everything is already tunneled. |
|
+1 |
This fixes a regression with databases connections that set an explicit `sslmode`. Previously we had disabled it for all cases, assuming no parameter would be provided. This time we adapt to the possible case, in which an SSL mode is provided, but in a notation not known by PostgreSQL. We have seen cases, in which `no-verify` is specified for configuring the `api-server` `psql` client, which we set to `require`, instead of the (possibly insecure) default of `prefer`. To cite https://www.postgresql.org/docs/current/libpq-ssl.html#LIBQ-SSL-CERTIFICATES "By default, PostgreSQL will not perform any verification of the server certificate." This differs from the default in the Postgres library we use `pq`, citing https://node-postgres.com/announcements#2020-02-25 "Now we will use the default ssl options to tls.connect which includes rejectUnauthorized being enabled. This means your connection attempt may fail if you are using a self-signed cert." As per that announcement, the behaviour is intentionally inherited from: - https://nodejs.org/api/tls.html#tls_tls_connect_options_callback As specifying an `sslmode`, even with `no-verify`, implies that we want to enforce a secure connection, we are falling back to a sane default, `require`. Reference: - https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS - https://github.com/brianc/node-postgres/blob/46cfb25baf8fdba87f71c3888fcb0021eaf829d3/packages/pg-connection-string/README.md?plain=1#L69-L72 - https://github.com/brianc/node-postgres/blob/master/packages/pg/lib/connection-parameters.js#L30-L31 - https://github.com/brianc/node-postgres/blob/master/packages/pg-connection-string/index.js#L98-L101 - brianc/node-postgres#2720
This fixes a regression with databases connections that set an explicit `sslmode`. Previously we had disabled it for all cases, assuming no parameter would be provided. This time we adapt to the possible case, in which an SSL mode is provided, but in a notation not known by PostgreSQL. We have seen cases, in which `no-verify` is specified for configuring the `api-server` `psql` client, which we set to `require`, instead of the (possibly insecure) default of `prefer`. To cite https://www.postgresql.org/docs/current/libpq-ssl.html#LIBQ-SSL-CERTIFICATES "By default, PostgreSQL will not perform any verification of the server certificate." This differs from the default in the Postgres library we use `pq`, citing https://node-postgres.com/announcements#2020-02-25 "Now we will use the default ssl options to tls.connect which includes rejectUnauthorized being enabled. This means your connection attempt may fail if you are using a self-signed cert." As per that announcement, the behaviour is intentionally inherited from: - https://nodejs.org/api/tls.html#tls_tls_connect_options_callback As specifying an `sslmode`, even with `no-verify`, implies that we want to enforce a secure connection, we are falling back to a sane default, `require`. Reference: - https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS - https://github.com/brianc/node-postgres/blob/46cfb25baf8fdba87f71c3888fcb0021eaf829d3/packages/pg-connection-string/README.md?plain=1#L69-L72 - https://github.com/brianc/node-postgres/blob/master/packages/pg/lib/connection-parameters.js#L30-L31 - https://github.com/brianc/node-postgres/blob/master/packages/pg-connection-string/index.js#L98-L101 - brianc/node-postgres#2720
|
There's always a risk associated with dropping down or disabling SSL so this should ideally be controlled parametrically. After playing around it seems the best option is to explicitly pass |
The default
sslmodein libpq isprefer:It should be possible to have similar fallback behavior in node-postgres.
Currently, the following will fail with a
The server does not support SSL connectionserror if the DB does not support TLS:This requires knowing ahead of time whether the server supports TLS or not, even if we don't care about TLS.
The text was updated successfully, but these errors were encountered: