Re: sslmode=require fallback

From: Greg Stark <stark(at)mit(dot)edu>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Christoph Berg <myon(at)debian(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jakob Egger <jakob(at)eggerapps(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sslmode=require fallback
Date: 2016-07-29 21:57:08
Message-ID: CAM-w4HP6bCzme1nF8wRH-QBT75LfsA0xmcmaWDQZhN4zjCqkzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 29, 2016 at 4:13 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Yes, I am thinking of a case where Postgres is down but a malevolent
> user starts a Postgres server on 5432 to gather passwords.

Or someone spoofs your DNS lookup, which is an attack that can
actually be done remotely in some cases.

For what it's worth the SCRAM work also addresses precisely this
danger though it doesn't prevent the attacker from pretending to be a
real server and capturing private data from the SQL updates.

Even in the case where there's no known server certificate it could
save the fingerprint seen once and require it not change. This proves
to be a headache to manage though. It's equivalent to the SSH
known_hosts scheme. How many times have you seen that warning message
and just automatically removed the entry in known_hosts without
verifying...

One day DNSSEC will solve all these problems though. Then you'll just
store the certificate in the DNS entry for the server and the client
will insist it match.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-07-29 22:57:14 Re: [sqlsmith] Failed assertion in joinrels.c
Previous Message Stephen Frost 2016-07-29 20:47:35 Re: pg_dumping extensions having sequences with 9.6beta3