Is it ok to be setting rejectUnauthorized to false in production PostgreSQL connections?

Question

We recently moved to Heroku and upon attempting to connect our apps to the DB, it kept rejecting our queries with the message "Self signed certificate". Passing in rejectUnauthorized solved for this but now I'm wondering, should we be doing this in production? If not, what is the appropriate way for us to be connecting to our Heroku PG Databases?

const pgp = require('pg-promise')(/*initOptions*/);
const {ConnectionString} = require('connection-string');

const cnObj = new ConnectionString(process.env.DATABASE_URL);

const cn = {
  host: cnObj.hostname,
  port: cnObj.port,
  database: cnObj.path?.[0],
  user: cnObj.user,
  password: cnObj.password,
  ssl: {
    rejectUnauthorized: false,
  },
};

const db = pgp(cn);

Corrected code for better `ConnectionString` usage. Other than that, it is not an issue with `pg-promise`, it is strictly authentication config, which has been addressed many times before - [look for the related issues](https://github.com/brianc/node-postgres/issues?q=Self+signed+certificate+heroku). — vitaly-t, Sep 15 '20 at 13:29
You will get to the truth, if you just follow [this thread](https://github.com/brianc/node-postgres/issues/2009). — vitaly-t, Sep 15 '20 at 14:13

Laurenz Albe · Accepted Answer · 2021-03-25T07:14:04.620

9

The risk you are running is that somebody gets between you and the Heroku server and impersonates the latter. They can then present their own certificate to you and negotiate a connection with you. The man in the middle can also pass the challenge from the server down to you and use your response to log into the database server in your stead.

All that assumes that the attacker has control over one of the network nodes between you and the Heroku server.

So I would say that while there is a residual risk, I wouldn't lose too much sleep over it, unless you are working with really sensitive data, in which case paranoia is a virtue.

edited Mar 25 '21 at 07:14

answered Sep 16 '20 at 06:41

Laurenz Albe

209,280
17
206
263

Downvoted. If they can impersonate the server, and the Postgres server uses a password-based authentication method (which I think Postgres on Heroku does), the attacker can just as well sniff the password. IMO this is not acceptable. – Michael Mar 25 '21 at 06:20
The password is never sent during password authentication. But you are right, the attacker can still login. I'll fix the answer. – Laurenz Albe Mar 25 '21 at 07:11
Thanks, upvoted again. for info, it seems Heroku uses the MD5 auth method by default (https://www.postgresql.org/docs/current/auth-password.html). That indeed does not send the password through the tunnel, instead an MD5 representation of username / password / salt is sent (https://www.pgcon.org/2014/schedule/attachments/330_postgres-for-the-wire.pdf) - see this answer for opinions on that: https://security.stackexchange.com/questions/41064/is-postgres-password-based-authentication-secure – Michael Mar 25 '21 at 11:47
@Michael The accepted answer to the question you link to is utterly wrong on many accounts. In fact, the way that PostgreSQL uses MD5 is safe, except that the hash is cheap to calculate, which makes brute force attack easier. – Laurenz Albe Mar 25 '21 at 12:00
Not sure if it is 'utterly wrong'. It may perhaps not stress the use of a random salt enough. Thinking further about it, the MITM attacker may simply ask the client for cleartext password authentication. The npm client used in the question builds on https://github.com/brianc/node-postgres which supports cleartext authentication and it's the server that decides. So, unacceptable. – Michael Mar 25 '21 at 18:01
Unacceptable if man-in-the-middle attacks are a danger for you. There is no need to complicate matters with security requirements that are not justified. – Laurenz Albe Mar 25 '21 at 18:09
Doesnt postgre encrypt the hash asynchronously? – a6i09per5f May 24 '22 at 20:12
@swisstackle No, why should it? And why does it matter? – Laurenz Albe May 24 '22 at 21:33

Is it ok to be setting rejectUnauthorized to false in production PostgreSQL connections?

1 Answers1

Linked