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/>
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 |
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 |