From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Subject: | Re: [PoC] Let libpq reject unexpected authentication requests |
Date: | 2023-02-28 23:38:21 |
Message-ID: | add8d351-1a03-378b-d8fa-9e2aa04bd0be@timescale.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/16/23 10:57, Jacob Champion wrote:
> v14 rebases over the test and solution conflicts from 9244c11afe2.
Since we're to the final CF for PG16, here's a rough summary.
This patchset provides two related features: 1) the ability for a client
to explicitly allow or deny particular methods of in-band authentication
(that is, things like password exchange), and 2) the ability to withhold
a client certificate from a server that asks for it.
Feature 1 was originally proposed to mitigate abuse where a successful
MITM attack can then be used to fish for client credentials [1]. It also
lets users disable undesirable authentication types (like plaintext) by
default, which seems to be a common interest. Both features came up
again in the context of proxies such as postgres_fdw, where it's
sometimes important that users authenticate using only their credentials
and not piggyback on the authority of the proxy host [2]. And another
use case for feature 2 just came up independently [3], to fix
connections where the default client certificate isn't valid for a
particular server.
Since this is all client-side, it's compatible with existing servers.
Also since it's client-side, it can't prevent connections from being
established by an eager server; it can only drop the connection once it
sees that its requirement was not met, similar to how we handle
target_session_attrs. That means it can't prevent a login trigger from
being processed on behalf of a confused proxy. (I think that would
require server-side support.)
0001 and 0002 are the core features. 0003 is a more future-looking
refactoring of the internals, to make it easier to handle more SASL
mechanisms, but it's not required and contains some unexercised code.
Thanks,
--Jacob
[1]
https://www.postgresql.org/message-id/fcc3ebeb7f05775b63f3207ed52a54ea5d17fb42.camel%40vmware.com
[2]
https://www.postgresql.org/message-id/20230123015255.h3jro3yyitlsqykp%40awork3.anarazel.de
[3]
https://www.postgresql.org/message-id/CAAWbhmh_QqCnRVV8ct3gJULReQjWxLTaTBqs%2BfV7c7FpH0zbew%40mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-02-28 23:42:48 | Re: Beautify pg_walinspect docs a bit |
Previous Message | Tom Lane | 2023-02-28 23:20:21 | Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL |