Re: Direct SSL connection with ALPN and HBA rules

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Daniel Gustafsson <daniel@yesql.se>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-05-13T14:54:30Z
Lists: pgsql-hackers
On 13/05/2024 16:55, Jelte Fennema-Nio wrote:
> On Mon, 13 May 2024 at 15:38, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Here's a patch to implement that.
> 
> +       if (conn->sslnegotiation[0] == 'd' &&
> +           conn->sslmode[0] != 'r' && conn->sslmode[0] != 'v')
> 
> I think these checks should use strcmp instead of checking magic first
> characters. I see this same clever trick is used in the recently added
> init_allowed_encryption_methods, and I think that should be changed to
> use strcmp too for readability.

Oh yeah, I hate that too. These should be refactored into enums, with a 
clear separate stage of parsing the options from strings. But we use 
that pattern all over the place, so I didn't want to start reforming it 
with this patch.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




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