Re: Direct SSL connection with ALPN and HBA rules
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Jacob Champion <jacob.champion@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-25T21:50:33Z
Lists: pgsql-hackers
On 25/04/2024 21:13, Jacob Champion wrote: > On Thu, Apr 25, 2024 at 10:35 AM Robert Haas <robertmhaas@gmail.com> wrote: >> Maybe I'm missing something here, but why doesn't sslnegotiation >> override sslmode completely? Or alternatively, why not remove >> sslnegotiation entirely and just have more sslmode values? I mean >> maybe this shouldn't happen categorically, but if I say I want to >> require a direct SSL connection, to me that implies that I don't want >> an indirect SSL connection, and I really don't want a non-SSL >> connection. My thinking with sslnegotiation is that it controls how SSL is negotiated with the server, if SSL is to be used at all. It does not control whether SSL is used or required; that's what sslmode is for. > I think that comes down to the debate upthread, and whether you think > it's a performance tweak or a security feature. My take on it is, > `direct` mode is performance, and `requiredirect` is security. Agreed, although the the security benefits from `requiredirect` are pretty vague. It reduces the attack surface, but there are no known issues with the 'postgres' or 'direct' negotiation either. Perhaps 'requiredirect' should be renamed to 'directonly'? > (Especially since, with the current implementation, requiredirect can > slow things down?) Yes: the case is gssencmode=prefer, kerberos credentical cache present in client, and server doesn't support GSS. With sslnegotiation='postgres' or 'direct', libpq can do the SSL negotiation over the same TCP connection after the server rejected the GSSRequest. With sslnegotiation='requiredirect', it needs to open a new TCP connection. > >> I think it's pretty questionable in 2024 whether sslmode=allow and >> sslmode=prefer make any sense at all. I don't think it would be crazy >> to remove them entirely. But I certainly don't think that they should >> be allowed to bleed into the behavior of new, higher-security >> configurations. Surely if I say I want direct SSL, it's that or >> nothing, right? > > I agree, but I more or less lost the battle at [1]. Like Matthias > mentioned in [2]: > >> I'm not sure about this either. The 'gssencmode' option is already >> quite weird in that it seems to override the "require"d priority of >> "sslmode=require", which it IMO really shouldn't. Yeah, that combination is weird. I think we should forbid it. But that's separate from sslnegotiation. -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Remove option to fall back from direct to postgres SSL negotiation
- fb5718f35ff6 17.0 landed
-
Reject SSL connection if ALPN is used but there's no common protocol
- 17a834a04d5a 17.0 landed
-
libpq: Enforce ALPN in direct SSL connections
- 03a0e0d4bb78 17.0 landed
-
libpq: If ALPN is not used, make PQsslAttribute(conn, "alpn") == ""
- 3c184092651b 17.0 landed
-
Fix documentation and comments on what happens after GSS rejection
- 5c9f35fc48ea 17.0 landed
-
doc: Add note to prevent server spoofing with SCRAM
- d0f4824a5410 16.0 cited