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);

Eligible

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. – Hegumen

You will get to the truth, if you just follow this thread. – Hegumen

Thank you @vitaly-t. A lifesaver as always – Eligible

Answer 1

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.

Hobbledehoy

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. – Cytolysis

The password is never sent during password authentication. But you are right, the attacker can still login. I'll fix the answer. – Hobbledehoy

Thanks, upvoted again. for info, it seems Heroku uses the MD5 auth method by default (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 (pgcon.org/2014/schedule/attachments/…) - see this answer for opinions on that: security.stackexchange.com/questions/41064/… – Cytolysis

@Cytolysis 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. – Hobbledehoy

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 github.com/brianc/node-postgres which supports cleartext authentication and it's the server that decides. So, unacceptable. – Cytolysis

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. – Hobbledehoy

Doesnt postgre encrypt the hash asynchronously? – Resemblance

@swisstackle No, why should it? And why does it matter? – Hobbledehoy