Re: Add "password_protocol" connection parameter to libpq
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: Stephen Frost <sfrost@snowman.net>, Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2019-08-19T05:51:00Z
Lists: pgsql-hackers
On Fri, Aug 16, 2019 at 02:11:57PM -0400, Jonathan S. Katz wrote: > To be pedantic, +1 on the channel_binding param. Seems like we are moving in this direction then. I don't object to the introduction of this parameter. We would likely want to do something for downgrade attacks in other cases where channel binding is not used, still there is verify-ca/full even in this case which offer similar protections for MITM and eavesdropping. > I would ask if scram-sha-256-plus makes the list if we have the > channel_binding param? No in my opinion. > If channel_binding = require, it would essentially ignore any non-plus > options in password_protocol and require scram-sha-256-plus. In a future > scram-sha-512 world, then having scram-sha-256-plus or > scram-sha-512-plus options in "password_protocol" then could be > necessary based on what the user would prefer or require in their > application. Not including scram-sha-512-plus or scram-sha-256-plus in the comma-separated list would be a problem for users willing to give for example scram-sha-256,scram-sha-512-plus as an authorized list of protocols but I don't think that it makes much sense as they basically require an SSL connection for tls-server-end-point per the second element. -- Michael
Commits
-
Add libpq parameter 'channel_binding'.
- d6e612f837e2 13.0 landed