On Wed, May 16, 2018 at 08:59:23PM +0900, Michael Paquier wrote: > On Wed, May 16, 2018 at 01:09:07PM +0300, Heikki Linnakangas wrote: > > I have to agree with Bruce, that it's pretty useless to implement channel > > binding, if there is no way to require it in libpq. IMHO that must be > > fixed. > > Wouldn't we want to also do something for the case where a client is > willing to use SCRAM but that the server forces back MD5? In which > case, one possibility is a connection parameter like the following, > named say authmethod: > - An empty value is equivalent to the current behavior, and is the > default. > - 'scram' means that client is willing to use SCRAM, which would cause a > failure if server attempts to enforce MD5. > - 'scram-plus' means that client enforces SCRAM and channel binding. > > Or we could just have a channel_binding_mode, which has a "require" > value like sslmode, and "prefer" mode, which is the default and the > current behavior... Still what to do with MD5 requests in this case?
Just to reiterate, MD5 and SCRAM-less-binding is designed to avoid packet _replay_. It assumes no man-in-the-middle has adjusted what is supported by the two endpoints. SCRAM-with-binding is the first password method that attempts to avoid man-in-the-middle attacks, and therefore is much less likely to be able to trust what the endpoints supports. I think it is really the channel_binding_mode that we want to control at the client. The lesser modes are much more reasonable to use an automatic best-supported negotiation, which is what we do now. FYI, I think the server could also require channel binding for SCRAM. We already have scram-sha-256 in pg_hba.conf, and I think scram-sha-256-plus would be reasonable. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
