Re: SCRAM with channel binding downgrade attack

On 28/05/18 04:23, Michael Paquier wrote:
> On Sat, May 26, 2018 at 11:42:38PM +0900, Michael Paquier wrote:
>> On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote:
>>> On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
>>>>
>>>> OK, I can live with that as well. So we'll go in the direction of two
>>>> parameters then:
>>>> - scram_channel_binding, which can use "prefer" (default), "require" or
>>>> "disable".
>>>> - scram_channel_binding_name, developer option to choose the type of
>>>> channel binding, with "tls-unique" (default) and "tls-server-end-point".
>>>> We could also remove the prefix "scram_". Ideas of names are welcome.
>>>
>>> scram_channel_binding_method?
>>
>> Or scram_channel_binding_type. The first sentence of RFC 5929 uses this
>> term.
>
> I just went with scram_channel_binding_mode (require, disable and
> prefer) and scram_channel_binding_type as parameter names, in the shape
> of the attached patch.

Thanks! Getting better.

There's one pretty fatal bug in this patch: If you use
"scram_channel_binding=require", we only fail the connection after going
through the motions of authenticating with whatever authentication the
server asked for. That's bad, because it means that the client will
merrily respond to a AUTH_REQ_PASSWORD request from the server, by
sending the password in cleartext.

That's not a new problem, but it makes the MITM protection fairly
pointless, if a fake server can acquire the user's password by simply
asking for it. The client will report a failed connection, but with the
user's password, Mallory won't need to act as a MITM anymore.

- Heikki