Re: Postgres 11 release notes

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Postgres 11 release notes
Date: 2018-05-17 13:38:36
Message-ID: CABUevEz8i4-fCS6d2VqF3bU02JbNwOF99mstT_x8y1y2nzzF+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

On Thu, May 17, 2018 at 2:56 AM, Michael Paquier <michael(at)paquier(dot)xyz>
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.
>

(apologies if this was covered earlier, as I'm entering late into the
discussion)

"ignored" in combination with a security parameter is generally a very very
red flag.

If the client requests channel binding and ends up using a non encrypted
connection, surely the correct thing to do is fail the connection, rather
than downgrade the authentication?

We should really make sure we don't re-implement something as silly as our
current "sslmode=prefer", because it makes no sense. From the client side
perspective, there really only needs to be two choices -- "enforce channel
binding at level <x>" or "meh, I don't care". In the "meh, I don't care"
mode, go with whatever the server picks (through enforcement in pg_hba.conf
for example).

> 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. And they *should* fail if they don't upgrade. That's what requirement
means... :)

What's the take of others? Magnus, Stephen or Heikki perhaps (you've
> been the most involved with SCRAM early talks)?
>

Saw it by luck. It would probably be better if it wasn't hidden deep in a
thread about release notes.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Kliukin 2018-05-17 13:49:37 'tuple concurrently updated' error w/o visible catalog updates
Previous Message Stefan Fercot 2018-05-17 13:37:42 Fwd: Question about xmloption and pg_restore

Browse pgsql-www by date

  From Date Subject
Next Message Bruce Momjian 2018-05-17 13:55:34 Re: Postgres 11 release notes
Previous Message Michael Paquier 2018-05-17 13:35:53 Re: Postgres 11 release notes