Re: Negotiating the SCRAM channel binding type

Greetings,

* Heikki Linnakangas (hlinnaka(at)iki(dot)fi) wrote:
> On 07/08/18 17:34, Stephen Frost wrote:
> >Now- if we thought that maybe there was some connection pooling solution
> >that could be made to work with SSL+SCRAM if channel binding is turned
> >off, then that's a use-case that maybe we should try and support, but
> >this notion that we need to be able to turn it off because there might
> >be a bug is hogwash, imv. Now, I haven't seen a pooling solution
> >actually figure out a way to do SSL+SCRAM even without channel binding,
> >and there might not even be a way, so I'm currently a -1 on adding an
> >option to disable it, but if someone turned up tomorrow with an credible
> >approach to doing that, then I'd +1 adding the option.
>
> Now that's a lot more compelling argument for having an option. Essentially,
> you might have a legitimate proxy or connection pooler that acts like a
> Man-In-The-Middle.
>
> The removed "channel_binding" libpq option wasn't very user-friendly, and
> wasn't very good for dealing with that scenario anyway; wouldn't you want to
> disable channel binding in the server rather than the client in that
> scenario? So I have no regrets in removing it. But going forward, we do need
> to put some thought in configuring this. We've talked a lot about a libpq
> option to require channel binding, but we should also have a server-side
> option to disable it.

Yeah, I'm pretty sure we'd need it on both sides. If we had it only on
one side or the other then you run into the risk of downgrade attacks
where the MITM is able to say "I don't support channel binding!" to both
sides, even when the actual libpq client and PG server do.

Thanks!

Stephen