public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Heikki Linnakangas <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Direct SSL connection with ALPN and HBA rules
Date: Tue, 23 Apr 2024 14:42:08 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAOYmi+kbYPX78nu0k7OODxUhoD6H1OXdugiMK1z9Nn33G-qdcQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
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.
>
> I'd be OK with that, although I still don't really see the point of forcing
> 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?
>
> Sounds complicated, and I don't really see the use case for controlling the
> direct SSL support in such a fine-grained fashion.
>
> 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 would
> be possible: reject SSLRequest or direct SSL connection immediately, if HBA
> doesn't allow non-SSL connections from that IP address. But that's not very
> 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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (28+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Direct SSL connection with ALPN and HBA rules
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox