Horton

Re: Direct SSL connection with ALPN and HBA rules

Jacob Champion <jacob.champion@enterprisedb.com>

View thread View on postgr.es
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Daniel Gustafsson <daniel@yesql.se>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-29T19:34:18Z
Lists: pgsql-hackers 
On Mon, Apr 29, 2024 at 12:32 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > On 29/04/2024 21:43, Jacob Champion wrote:
> > > But if you're in that situation, what does the use of directonly give
> > > you over `sslnegotiation=direct`? You already know that servers
> > > support direct, so there's no additional performance penalty from the
> > > less strict mode.
> >
> > Well, by that argument we don't need requiredirect/directonly at all.
> > This goes back to whether it's a security feature or a performance feature.
>
> That's what I've been trying to argue, yeah. If it's not a security
> feature... why's it there?

Er, I should clarify this. I _want_ requiredirect. I just want it to
be a security feature.

--Jacob

Commits

  1. Remove option to fall back from direct to postgres SSL negotiation

  2. Reject SSL connection if ALPN is used but there's no common protocol

  3. libpq: Enforce ALPN in direct SSL connections

  4. libpq: If ALPN is not used, make PQsslAttribute(conn, "alpn") == ""

  5. Fix documentation and comments on what happens after GSS rejection

  6. doc: Add note to prevent server spoofing with SCRAM