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