On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote:
> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote:
> > 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.
>
> Noted. Which means that the parameter is ignored when using a non-SSL
> connection, as well as when the server tries to enforce the use of
> anything else than SCRAM.
Uh, a man-in-the-middle could prevent SSL or ask for a different
password authentication method and then channel binding would not be
used. I think when you say you want channel binding, you have to fail
if you don't get it.
> > 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.
>
> Noted as well. There is of course the question of v10 libpq versions
> which don't support channel binding, but if an admin is willing to set
> up scram-sha-256-plus in pg_hba.conf then he can request his users to
> update his drivers/libs as well.
Yes, I don't see a way around it. Once you accept that someone in the
middle can change what you request undetected, then you can't do
fallback. Imagine a man-in-the-middle with TLS where the
man-in-the-middle allows the two end-points to negotiate the shared
secret, but the man-in-the-middle forces a weak cipher. This is what is
happening with Postgres when the man-in-the-middle forces a weaker
authentication method.
--
Bruce Momjian <bruce@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 +
