Re: [HACKERS] Channel binding support for SCRAM-SHA-256

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL JDBC List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: [HACKERS] Channel binding support for SCRAM-SHA-256
Date: 2017-06-06 06:40:05
Message-ID: CAB7nPqQOFSn-PYpEXawFx5Gh0CSwX6kPR4ib+T5qmd7OVsV=PA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I don't have any issue with asking that Michael, or someone, to go look
> at other OpenSSL-using implementations which support channel binding.

I don't see the implementation of other TLS/SSL as a requirement for
channel binding with OpenSSL, and I have no plans to investigate that.
What is clearly a requirement though is to design a set of API generic
enough for the backend and the frontend to fetch the TLS unique
message, and what's needed for endpoint so as any implementation can
plug in easily with PG's channel binding code.

> What I find somewhat objectionable is the notion that if we don't have 5
> different TLS/SSL implementations supported in PG and that we've tested
> that channel binding works correctly among all combinations of all of
> them, then we can't accept a patch implementing it. I'm exaggerating
> for effect here, of course, and you've agreed that a full, committable,
> implementation isn't necessary, and I agreed with that, but we still
> seem to have a different level of expectation regarding what needs doing
> here. I don't know that we'll ever be able to nail down the exact
> location of the line in the sand that needs to be crossed here, or agree
> to it, so I'd suggest that we let them continue their efforts to work
> together and provide a patch which they feel is ready to be commented on
> by committers. Perhaps we'll find that, regardless of where the line
> was drawn exactly, they've crossed it.

As far as I can see, there are a couple of things that I still need to
work on to make people happy:
- Rework the generic APIs for TLS finish and endpoint so as any
implementation can use channel binding without inducing any extra code
footprint to be-secure.c and fe-secure.c.
- Implement endpoint, as Alvaro is saying for JDBC that would be nicer.
- Have a couple of tests for channel binding to allow people to test
the feature easily. Those will be in src/test/ssl/. It would be nice
as well to be able to enforce the channel binding type on libpq-side,
which is useful at least for testing. So we are going to need an
environment variable for this purpose, and a connection parameter.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message amul sul 2017-06-06 07:33:58 Re: [POC] hash partitioning
Previous Message Beena Emerson 2017-06-06 06:34:02 Re: Default Partition for Range

Browse pgsql-jdbc by date

  From Date Subject
Next Message Stephen Frost 2017-06-06 12:29:25 Re: [HACKERS] Channel binding support for SCRAM-SHA-256
Previous Message Michael Paquier 2017-06-06 06:32:46 Re: [HACKERS] Channel binding support for SCRAM-SHA-256