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
