On Thu, May 17, 2018 at 10:05:25AM -0400, Bruce Momjian wrote:
> Agreed.  The problem was so glaring that I assumed I was not
> understanding it.  I have modified this email subject so users will
> hopefully read back in this thread to see the details.

Okay, let's use this new thread then for the follow-up discussion.  For
people wondering, this basically refers to the following message from
Bruce and Heikki:

There are actually two problems which have been touched in this
1) A client using libpq may be forced by a rogue server to not use
channel binding even if it is willing to do so.  For example, a v11
libpq with a v10 server enters in this category.  An idea here would be
to provide an extra connection parameter which allows the client to
reject an access to a server if channel binding is not supported.  One
idea is something I mentioned here:
So we could have channel_binding_mode, which has a 'prefer' mode, which
is the actual default we have in the tree, as well as a 'require' mode,
which allows the client to fail connection if a server does not publish
the SCRAM-PLUS mechanism after the initial authentication message
2) Allow clients to connect to servers only if they use channel
binding.  This goes with a server-side hba configuration, like
scram-sha-256-plus to not allow access to clients in a SCRAM
authentication if they don't have channel binding support.

From a security point of view, 1) is important for libpq, but I am not
much enthusiast about 2) as a whole.  The backend has proper support for
channel binding, hence other drivers speaking the protocol could have
their own restriction mechanisms.

I actually touched a bit what's being discussed here as part of the
channel binding thread:
However per what I read this does not cover the need to allow the client
to allow that channel binding *has* to be used depending on its

I'd like to mention as well that I touched the topic during the
unconference of PGConf Asia last December:

Any ideas raised there did not get much enthusiam from the
participants.  Magnus and Bruce have participated in the conference,
perhaps you were not at my unconf session..

Attachment: signature.asc
Description: PGP signature

Reply via email to