On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier <mich...@paquier.xyz> wrote: > > 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?
I think it would be nice to have an option like that. Whether it's done now or in 18, I don't have a strong opinion about. But I do think it'd be helpful to have a consensus on whether or not this is a security improvement, or a performance enhancement only, before adding said option. As it's implemented, if the requiredirect option doesn't actually requiredirect, I think it looks like security but isn't really. (My ideal server-side option removes all plaintext negotiation and forces the use of direct SSL for every connection, paired with a new postgresqls:// scheme for the client. But I don't have any experience making a switchover like that at scale, and I'd like to avoid a StartTLS-vs-LDAPS sort of situation. That's obviously not a conversation for 17.) As for HBA control: overall, I don't see a burning need for an HBA-based configuration, honestly. I'd prefer to reduce the number of knobs and make it easier to apply the strongest security with a broad brush. --Jacob
