Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 23 Apr 2024 14:42:08 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Direct SSL connection with ALPN and HBA rules
Message-ID: <ZidKMB1tcgM3bzFZ@paquier.xyz>
References: <ZiH7vHwEJeRKHlST@paquier.xyz>
 <c786e226-4039-4522-ba07-92501fce9b6a@iki.fi>
 <CAOYmi+kbYPX78nu0k7OODxUhoD6H1OXdugiMK1z9Nn33G-qdcQ@mail.gmail.com>
 <a0983295-67ae-487e-84e3-6e1148af3a25@iki.fi>
 <ZiYPmUZjcQtPz2j7@paquier.xyz>
 <feebbeee-df5f-484f-b07e-062bd0230bd2@iki.fi>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="jpqMtVWBerLYrPiC"
Content-Disposition: inline
In-Reply-To: <feebbeee-df5f-484f-b07e-062bd0230bd2@iki.fi>
Archived-At: <https://www.postgresql.org/message-id/ZidKMB1tcgM3bzFZ%40paquier.xyz>
Precedence: bulk


--jpqMtVWBerLYrPiC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> On 22/04/2024 10:19, Michael Paquier wrote:
>> As a whole, I can get behind a unique GUC that forces the use of
>> direct.  Or, we could extend the existing "ssl" GUC with a new
>> "direct" value to accept only direct connections and restrict the
>> original protocol (and a new "postgres" for the pre-16 protocol,
>> rejecting direct?), while "on" is able to accept both.
>=20
> I'd be OK with that, although I still don't really see the point of forci=
ng
> this from the server side. We could also add this later.

I'd be OK with doing something only in v18, if need be.  Jacob, what
do you think?

>> Hmm.  Splitting the logic checking HBA entries (around check_hba) so
>> as we'd check for a portion of its contents depending on what the
>> server has received or not from the client would not be that
>> complicated.  I'd question whether it makes sense to mix this
>> information within the same configuration files as the ones holding
>> the current HBA rules.  If the same rules are used for the
>> pre-startup-packet phase and the post-startup-packet phase, we'd want
>> new keywords for these HBA rules, something different than the
>> existing sslmode and no sslmode?
>=20
> Sounds complicated, and I don't really see the use case for controlling t=
he
> direct SSL support in such a fine-grained fashion.
>=20
> It would be nice if we could reject non-SSL connections before the client
> sends the startup packet, but that's not possible because in a plaintext
> connection, that's the first packet that the client sends. The reverse wo=
uld
> be possible: reject SSLRequest or direct SSL connection immediately, if H=
BA
> doesn't allow non-SSL connections from that IP address. But that's not ve=
ry
> interesting.

I'm not completely sure, actually.  We have the APIs to do that in
simple ways with existing keywords and new options.  And there is some
merit being able to have more complex connection policies.  If both of
you object to that, I won't insist.

> HBA-based control would certainly be v18 material.

Surely.
--
Michael

--jpqMtVWBerLYrPiC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmYnSjAACgkQnvQgOdby
QH08FA//XIQ3qisF7xUMlEz1o1K+B0QPUpJb5cnGwcjElHH1BBUW0rt2Err/ZsM7
TZmDCzUgLmxVqKcPvzA4sFk6D6QAh+fN87HS4dReDDkmDl8qyi4g3dWNN4dJGNmK
Nj5Z8RWdzjiNABT38dP0EhXh+ewiq71xCvo9qlg7dBB7ILBW2XVp8Uw5FOJoEzmw
CkxdEsyzcFcPOayUXclH4FweOsfPhc30luJxkBSFXbvOhZ3WjVDLPxRvt89SmNaB
6St2in6os3GZISneezCBVZknR+8INDWU1h9HgqZ5JEqOc8Sjfwpo+1BC0ZNlSjml
bC7re2pz3s1oMInvpME7uDSvH8A7ouoTtDJ56k8QN3gVd0+nl8C5vEkeIXDQLfpo
T1FlehU8fq0jkHhF1AvGxTD6q9/8r49w9IiS9vGVmPYe6H4tAbbunsFkV3JbEjsp
eHO0grzPhnpC3IbUA5UF96OxC4IAYDwg+KnmhiaDtUrSBeX/DAC+14rD1HcBTpcF
7emD0GfUVwzSnYv5mD0PjJMAXgBswxhplVhBwdIJOeclcexy9JcMfGb80Xl2EkRs
GblYNwHX2hMWb4zDMiO/kspeCrWs8nczvQsGmHg9Sd76lVK7Fv63yzAWPaNytK/9
GMW56t+KiWKlVwvVVH+4YDfLotkfZdfQ0KD+DvTF01r1DS0+edI=
=S866
-----END PGP SIGNATURE-----

--jpqMtVWBerLYrPiC--