Re: Postgres 11 release notes - Mailing list pgsql-hackers

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@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 +