> 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
