Re: Direct SSL connection with ALPN and HBA rules

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Jacob Champion <jacob.champion@enterprisedb.com>, Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-05-16T14:08:14Z
Lists: pgsql-hackers
> On 16 May 2024, at 15:54, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Ok, yeah, I can see that now. Here's a new version to address that. I
>> merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,
>> ENC_SSL. The places that need to distinguish between them now check
>> conn-sslnegotiation. That seems more clear now that there is no fallback.
> 
> Unless there is a compelling reason to do otherwise, we should
> expedite getting this committed so that it is included in beta1.
> Release freeze begins Saturday.

+1. Having reread the thread and patch I think we should go for this one.

./daniel


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