On Thu, Jun 28, 2018 at 10:04:05AM +0200, Peter Eisentraut wrote: > 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.
The issue is that our different password methods were designed to do a best-effort at preventing _passive_ snoopers from decrypting or reusing passwords. With channel binding, we are trying to prevent _active_ network attacks, and our fallback behavior eliminates the protection that channel binding provides. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
