Message-ID: <add8d351-1a03-378b-d8fa-9e2aa04bd0be@timescale.com>
Date: Tue, 28 Feb 2023 15:38:21 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [PoC] Let libpq reject unexpected authentication requests
Content-Language: en-US
From: Jacob Champion <jchampion@timescale.com>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Cc: Aleksander Alekseev <aleksander@timescale.com>,
 Michael Paquier <michael@paquier.xyz>,
 Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 "David G. Johnston" <david.g.johnston@gmail.com>
References: 
 <CAAWbhmiRxVNsfaq8DLgxoAh2TBu1SthP9jycutXBz32Z2k80pw@mail.gmail.com>
 <949f1c20-771c-aef7-058f-2c10885db955@enterprisedb.com>
 <CAAWbhmimxNiGMDHju7FsEtem4Rmk1enQ_-ypenjkTQnNPLouMA@mail.gmail.com>
 <8e2e5fb6-8225-de8a-b0f9-178c27402367@enterprisedb.com>
 <d192cc5f-e023-fed5-d82c-dc4fb54773c2@timescale.com>
 <CAAWbhmgjs6kSm1n25a-+ZKOb5QnEzxerMfcmML_rXz2JTKvrpw@mail.gmail.com>
 <Y3SMDoHfS8sy2wwW@paquier.xyz>
 <CAAWbhmixDLmLMNUcMgCGYbG_z85umzUAD_6v=9bZHvxsjnHLpA@mail.gmail.com>
 <9de74f8d-fbf4-63d9-7bcb-b9c27edf8b73@enterprisedb.com>
 <CAJ7c6TP0em9qcoh_iN_8xdgCwg-fsqSxngXydOBGWyKsmBMJ7A@mail.gmail.com>
 <Y9ms6HPSxEiXpw+4@paquier.xyz>
 <CAAWbhmihPDBe+sHPxY0N+9YUj8MoRErdeSYjMeiic0evLWYtmQ@mail.gmail.com>
In-Reply-To: 
 <CAAWbhmihPDBe+sHPxY0N+9YUj8MoRErdeSYjMeiic0evLWYtmQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/add8d351-1a03-378b-d8fa-9e2aa04bd0be%40timescale.com>
Precedence: bulk

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