> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
