On Wed, Jul 5, 2017 at 9:32 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Jul 6, 2017 at 10:03 AM, Tatsuo Ishii <is...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
