Re: [HACKERS] SCRAM auth and Pgpool-II - Mailing list pgsql-hackers

On Sat, Jul 8, 2017 at 1:24 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

I recall vaguely Ishii-san mentioning me at PGcon that pgpool was
actually cheating, but my memories are a bit fuzzy for this part.

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

We may be misunderstanding each other then. The solution I am
proposing, or at least the solution that I imagine should be done but
my pgpool-fu is limited, is to keep around connection context and SSL
context to handle properly connections messages, and switch between
them. When using channel binding, the client needs the server
certificate for end-point and the TLS finish message which are both
stored in the SSL context after the handshake. So you need to cache
that for each server.

One problem is that pgpool does not use directly libpq but tries to
handle things by itself at protocol level, so it needs to replicate a
lot of existing APIs. Postgres-XC/XL use a connection pooler,
presumably XL uses even a background worker for this stuff since it
has been integrated with Postgres 9.3. And this stuff use libpq. This
makes life way easier to handle context data on a connection basis.
Those don't need to handle protocol-level messages either, which is
perhaps different from what pgpool needs.

In short I would think that pgpool needs first to un-cheat its
handling with MD5, which is likely here to simplify its code.
-- 
Michael