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: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-25T16:28:16Z
Lists: pgsql-hackers 
On Thu, Apr 25, 2024 at 9:17 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> It is difficult to imagine a world in which we have both requiredirect
> and forcedirect and people are not confused.

Yeah... Any thoughts on a better scheme? require_auth was meant to
lock down overly general authentication; maybe a require_proto or
something could do the same for the transport?

I hate that we have so many options that most people don't need but
take precedence, especially when they're based on the existence of
magic third-party environmental cues (e.g. Kerberos caches). And it
was nice that we got sslrootcert=system to turn on strong security and
reject nonsensical combinations. If someone sets `requiredirect` and
leaves the default sslmode, or chooses a weaker one... Is that really
useful to someone?

--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