On 6/28/18 09:35, Magnus Hagander wrote: > No, we absolutely still have SCRAM channel binding. > > *libpq* has no way to *enforce* it, meaning it always acts like our > default SSL config which is "use it if available but if it's not then > silently accept the downgrade". From a security perspective, it's just > as bad as our default ssl config, but unlike ssl you can't configure a > requirement in 11.
Isn't this similar to what happened whenever we added a new or better password method? A MITM that didn't want to bother cracking MD5 could just alter the stream and request "password" authentication. Same with MD5->SCRAM, SCRAM->SCRAM+CB, and even a hypothetical future change in the SCRAM hashing method. Clearly, we need a more comprehensive solution for this.
That is sort of the gist of the discussion, yes. It is.
So if you just enabled scram channel binding, an attacker could just turn off scram completely.
That's why we need a solution that covers the full problem, which is why it needs to be thought of as one problem so we don't end up with a fragmented solution.