Re: Postgres 11 release notes

On Tue, May 15, 2018 at 08:10:20AM +0900, Michael Paquier wrote:
> On Mon, May 14, 2018 at 04:04:58PM -0400, Bruce Momjian wrote:
> > So, channel binding has had me confused since I first heard about it. I
> > have done some research and reworded the commit with the attached
> > first patch.
>
> pg11.diff looks roughly fine to me.
>
> > Also, I have created a second patch which actually explains the two
> > SCRAM channel binding options and how the work.
>
> + The list of channel binding types supported by the server are
> + listed in <xref linkend="sasl-authentication"/>. An empty value
> + specifies that the client will not use channel binding. If this
> + parameter is not specified, <literal>tls-unique</literal> is used,
> + if supported by both server and client.
>
> OK, that's simple enough for users, and we talk about the libpq
> parameter here.

Great, committed.

> The second paragraph is also a nice addition. You really looked at this
> stuff!

Committed too.

Yeah, it bugs me when I hear terms thrown around but can't get to the
details of what is happening. This PDF unlocked it for me:

http://www.manulis.eu/papers/MaStDe_SSR14.pdf

> > One question I do have is how do we prevent a fake server in the middle
> > from pretending it is a PG 10 server and therefore avoiding channel
> > binding protections? I don't see any channel binding options in
> > pg_hba.conf, and while libpq has options, they are explained with "This
> > parameter is mainly intended for protocol testing."
>
> The answer is that you cannot do that now, as much as you cannot have a
> client forbid connection attempt if the client requests SCRAM but the
> server downgrades to MD5. I had a topic on the matter at an unconf
> session at the last PGAsia, and except for administrators which forgot
> to upgrade a set of servers that was not something worth complicating
> the code for, at least that's the conclusion which came out of the
> session. At the end, this is not actually something that you would
> control from the server if you care about security, but something which
> is controlled from the client. The limitations that we have know are
> partially due to the way libpq handles the authentication protocol.
> Hence if you want to prevent servers attempting to do downgrades, you
> need options like sslmode saying those things from the client point of
> view:
> - I want SCRAM, but refuse connection request if server attempts MD5 or
> something else.
> - I want SCRAM and channel binding, but refuse connection request if
> server does not advertise channel binding to the client.

Agreed. The libpq parameters don't help, I assume.

> There may be value to an server side parameter which forces clients to
> use channel binding even if the server has advertised the channel
> binding SASL mechanism, and even if connection is made with SSL, but
> that's not a downgrade-attack prevention.

What TLS does is to mix the offered ciphers into the negotiation hash so
a man-in-the-middle can't pretend it doesn't support something. Could
we do something like that here?

I have to question the value of man-in-the-middle protection that is so
easily bypassed.

--
Bruce Momjian <bruce(at)momjian(dot)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 +