On Wed, Jul 5, 2017 at 9:32 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Jul 6, 2017 at 10:03 AM, Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
>> For Pgpool-II, things would go as follows:
>>
>> 1) clients sends user name to Pgpool-II.
>> 2) Pgpool-II forwards it to PostgreSQL servers.
>> 3) Each PostgreSQL server sends their own salt to Pgpool-II.
>> 4) Pgpool-II is confused because there are multiple salts and each has
>> different values. The client only accepts single salt obviously.
>
> Couldn't you cache one single SASL exchange status for each
> connection, meaning one PGconn saved for each? As the challenge sent
> by the server and the response generated by the client are different
> by design, I am afraid you would need to do that anyway in this
> context (Isn't PG-pool using already the weaknesses of MD5 to make
> things easier?).
I think it is. From a security point of view, the fact that the same
salt is always used for the same username is a weakness of md5
authentication which SCRAM corrects.
IIUC, things will get even worse once channel binding is committed,
presumably for PostgreSQL 11. The point of channel binding is to
guarantee that you are conducting the authentication exchange with the
target server, not some intermediate proxy that might be conducting a
hostile MITM attack. pgpool may not be a hostile attack, but it is
acting as a MITM, and channel binding is going to figure that out and
fail the authentication. So unless I'm misunderstanding, the solution
you are proposing figures to have a very limited shelf life.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company