From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | michael(dot)paquier(at)gmail(dot)com |
Cc: | sfrost(at)snowman(dot)net, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SCRAM auth and Pgpool-II |
Date: | 2017-07-13 08:35:05 |
Message-ID: | 20170713.173505.352934060469538911.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> What I am suggesting here is that in order to handle properly SCRAM
> with channel binding, pgpool has to provide a different handling for
> client <-> pgpool and pgpool <-> Postgres. In short, I don't have a
> better answer than having pgpool impersonate the server and request
> for a password in cleartext through an encrypted connection between
> pgpool and the client if pgpool does not know about it, and then let
> pgpool do by itself the SCRAM authentication on a per-connection basis
> with each Postgres instances. When using channel binding, what would
> matter is the TLS finish (for tls-unique) or the hash server
> certificate between Postgres and pgpool, not between the client and
> pgpool. But that's actually the point you are raising here:
Using a clear text password would not be acceptable for users even
through an encrypted connection, I think.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-07-13 09:23:00 | PgFDW connection invalidation by ALTER SERVER/ALTER USER MAPPING |
Previous Message | Dean Rasheed | 2017-07-13 08:19:28 | Re: Multi column range partition table |