On 24/11/2021 07:09, Michael Paquier wrote:
On Tue, Nov 23, 2021 at 02:18:30PM -0500, Tom Lane wrote:
Jacob Champion <pchamp...@vmware.com> writes:
= Client-Side Auth Selection =
The second request is for the client to stop fully trusting the server
during the authentication phase. If I tell libpq to use a client
certificate, for example, I don't think the server should be allowed to
extract a plaintext password from my environment (at least not without
my explicit opt-in).
Yeah. I don't recall whether it's been discussed in public or not,
but it certainly seems like libpq should be able to be configured so
that (for example) it will never send a cleartext password. It's not
clear to me what extent of configurability would be useful, and I
don't want to overdesign it --- but that much at least would be a
good thing.
I recall this part being discussed in public, but I cannot put my
finger on the exact thread. I think that this was around when we
discussed the open items of 10 or 11 for things around channel binding
and how libpq was sensitive to downgrade attacks, which would mean
around 2016 or 2017. I also recall reading (writing?) a patch that
introduced a new connection parameter that takes in input a
comma-separated list of keywords to allow the user to choose a set of
auth methods accepted, failing if the server is willing to use a
method that does not match with what the user has put in his list.
Perhaps this last part has never reached -hackers though :)
Anyway, the closest thing I can put my finger on now is that:
https://www.postgresql.org/message-id/c5cb08f4cce46ff661ad287fadaa1...@postgrespro.ru
Here's a thread:
https://www.postgresql.org/message-id/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com
The result of that thread was that we added the
channel_binding=require/prefer/disable option.
- Heikki
