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
