Re: Direct SSL connection with ALPN and HBA rules

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Robert Haas <[email protected]>
To: Jacob Champion <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Direct SSL connection with ALPN and HBA rules
Date: Tue, 23 Apr 2024 13:43:34 -0400
Message-ID: <CA+TgmoaLpDVY2ywqQUfxvKEQZ+nwkabcw_f=i4Zyivt9CLjcmA@mail.gmail.com> (raw)
In-Reply-To: <CAOYmi+n57x+8DVi9J+dGmFQo+2Eb+bg_+geH=jqfh3E=NWHfOA@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CAOYmi+kbYPX78nu0k7OODxUhoD6H1OXdugiMK1z9Nn33G-qdcQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAOYmi+n57x+8DVi9J+dGmFQo+2Eb+bg_+geH=jqfh3E=NWHfOA@mail.gmail.com>

On Tue, Apr 23, 2024 at 1:22 PM Jacob Champion
<[email protected]> wrote:
> On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier <[email protected]> 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

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], [email protected]
  Subject: Re: Direct SSL connection with ALPN and HBA rules
  In-Reply-To: <CA+TgmoaLpDVY2ywqQUfxvKEQZ+nwkabcw_f=i4Zyivt9CLjcmA@mail.gmail.com>

* 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