On Thu, Feb 21, 2019 at 08:32:01PM +0100, Peter Eisentraut wrote:
> On 2019-02-21 05:47, Michael Paquier wrote:
>> if (conn->ssl_in_use)
>> + {
>> + /*
>> + * The server has offered SCRAM-SHA-256-PLUS,
>> which is only
>> + * supported by the client if a hash of the
>> peer certificate
>> + * can be created.
>> + */
>> +#ifdef HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH
>> selected_mechanism = SCRAM_SHA_256_PLUS_NAME;
>> +#endif
>> + }
>
> Is that right? Won't we then just select nothing if the macro is not
> defined?In the context of an SSL connection, the server would send both SCRAM and SCRAM_PLUS as valid mechanisms if it supports channel binding (HAVE_BE_TLS_GET_CERTIFICATE_HASH). If the server does not support channel binding, then only SCRAM is sent. So you have the following possible cases for an SSL connection: 1) Server supports channel binding, sends SCRAM_PLUS and SCRAM as allowed mechanisms. 1-1) Client supports channel binding, and it chooses SCRAM_PLUS. 1-2) Client does not support channel binding, and it chooses SCRAM. 2) Server does not support channel binding, sends SCRAM as allow mechanism. 2-1) Client supports channel binding, still it has no choice but to choose SCRAM. 2-2) Client does not support channel binding, it chooses SCRAM. On HEAD, the bug you have spotted would cause case 1-2) to fail as the client thinks that it should choose SCRAM_PLUS even if it does not support it, causing a failure. My patch changes things so as SCRAM gets chosen instead of SCRAM_PLUS as the server sends both SCRAM and SCRAM_PLUS to the client as possible choices, still the client is not able to handle SCRAM_PLUS. Does this explanation make sense? -- Michael
signature.asc
Description: PGP signature
