On 1/2/18 18:35, Michael Paquier wrote:
> On Tue, Jan 02, 2018 at 10:35:16AM -0500, Peter Eisentraut wrote:
>> I see a potential problem with the SCRAM channel binding support.
>> GnuTLS will not support tls-server-endpoint, so we'll need to check what
>> happens when a client requests that. (That's not the problem of this
>> patch, however.)
>
> Doesn't it depend on the first patch merged into HEAD? At the end we'll
> need to make be_tls_get_certificate_hash() generate an ereport() with
> ERRCODE_FEATURE_NOT_SUPPORTED and have pgtls_get_peer_certificate_hash()
> return NULL with conn->errorMessage properly filled.
The problem I see is that SCRAM doesn't really support the negotiation
of the channel binding type. The client picks one, and the server
either accepts it or the whole thing dies.
One scenario is that if GnuTLS goes in, it's quite plausible that the
PG11 packages for Debian and Ubuntu will use it by default. But if it
doesn't support tls-server-endpoint, then a JDBC client (assuming
channel binding support is added) can't connect to such a server with
SCRAM authentication over SSL (which we hope will be a popular
configuration), unless they manually disable channel binding altogether
using the new scramchannelbinding connection option. That would be a
very poor experience.
I think the solution is that we need to require that all SSL server-side
implementations support all channel binding types.
I think that can probably be done with GnuTLS, but we'd need to check
that out a bit.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services