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

From Tatsuo Ishii
Subject Re: [HACKERS] SCRAM auth and Pgpool-II
Date
Msg-id 20170708.085757.352237085122780835.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: [HACKERS] SCRAM auth and Pgpool-II  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] SCRAM auth and Pgpool-II
List pgsql-hackers
> I recall vaguely Ishii-san mentioning me at PGcon that pgpool was
> actually cheating, but my memories are a bit fuzzy for this part.

What I meant by "cheating" was, Pgpool-II behaves as if PostgreSQL
server in md5 auth.

For more details what Pgpool-II actually does in md5 auth, please see:

https://pgpool.net/mediawiki/index.php/FAQ#How_does_pgpool-II_handle_md5_authentication.3F

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

Yeah, I wish I could use libpq in Pgpool-II. Unfortunately libpq does
not provide necessary features what Pgpool-II 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.

See the link above why it's not possible.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] SCRAM auth and Pgpool-II
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Rust bindings to pgtypes lib