Re: Negotiating the SCRAM channel binding type

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Negotiating the SCRAM channel binding type
Date: 2018-08-07 11:40:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
> On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> Well, it'd be useless for users, there is no reason to switch off channel
>> binding if both the client and server support it. It might not add any
>> security you care about, but it won't do any harm either. The
>> non-channel-binding codepath is still exercised with non-SSL connections.
> Is that true? What if it makes a connection fail that you wanted to
> succeed? Suppose we discover a bug that makes connections using
> channel binding fail on Thursdays.

Well, as things stand today on HEAD, if channel binding has a bug, this
makes the SCRAM authentication not able to work over SSL, hence you need
to either drop SSL, SCRAM or patch libpq so as the client tells the
server that it does not want to use channel binding. None of those are
appealing. Before 7729113, the client still had the choice to enforce
channel binding to not be used over SSL, which I think is a win to
bypass any potential future bugs. On top of that, we can test
automatically for *any* future SSL implementations that (SSL + SCRAM +
no channel binding) actually works properly, which is, it seems at least
to me, a good thing to get more confidence when a new SSL implementation
is added.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Erich Schubert 2018-08-07 11:58:11 Re: BUG #15307: Low numerical precision of (Co-) Variance
Previous Message Marina Polyakova 2018-08-07 10:56:50 Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors