Re: Negotiating the SCRAM channel binding type - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Negotiating the SCRAM channel binding type
Date
Msg-id 20180807114043.GD19883@paquier.xyz
Whole thread Raw
In response to Re: Negotiating the SCRAM channel binding type  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Negotiating the SCRAM channel binding type
List 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@iki.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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Marina Polyakova
Date:
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Next
From: Jesper Pedersen
Date:
Subject: Re: partition tree inspection functions