Re: Direct SSL connection with ALPN and HBA rules

On Tue, Apr 23, 2024 at 1:22 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier <michael@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.

I've not followed this thread closely enough to understand the comment
about requiredirect maybe not actually requiring direct, but if that
were true it seems like it might be concerning.

But as far as having a GUC to force direct SSL or not, I agree that's
a good idea, and that it's better than only being able to control the
behavior through pg_hba.conf, because it removes room for any possible
doubt about whether you're really enforcing the behavior you want to
be enforcing. It might also mean that the connection can be rejected
earlier in the handshaking process on the basis of the GUC value,
which could conceivably prevent a client from reaching some piece of
code that turns out to have a security vulnerability. For example, if
we found out that direct SSL connections let you take over the
Pentagon before reaching the authentication stage, but for some reason
regular connections don't have the same problem, being able to
categorically shut off direct SSL would be valuable.

However, I don't really see why this has to be done for this release.
It seems like a separate feature from direct SSL itself. If direct SSL
hadn't been committed at the very last minute, then it would have been
great if this had been done for this release, too. But it was. The
moral we ought to take from that is "perhaps get the big features in a
bit further in advance of the freeze," not "well we'll just keep
hacking after the freeze."

--
Robert Haas
EDB: http://www.enterprisedb.com