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>,
Daniel Gustafsson <daniel@yesql.se>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier
<michael@paquier.xyz>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-04-29T19:06:27Z
Lists: pgsql-hackers
On 29/04/2024 21:43, Jacob Champion wrote: > On Mon, Apr 29, 2024 at 1:38 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> If you only >> have v17 servers in your environment, so you know all servers support >> direct negotiation if they support SSL at all, but a mix of servers with >> and without SSL, sslnegotiation=directonly would reduce roundtrips with >> sslmode=prefer. > > 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. There is a small benefit with sslmode=prefer if you connect to a server that doesn't support SSL, though. With sslnegotiation=direct, if the server rejects the direct SSL connection, the client will reconnect and try SSL with SSLRequest. The server will respond with 'N', and the client will proceed without encryption. sslnegotiation=directonly removes that SSLRequest attempt, eliminating one roundtrip. >> Making requiredirect to imply sslmode=require, or error out unless you >> also set sslmode=require, feels like a cavalier way of forcing SSL. We >> should have a serious discussion on making sslmode=require the default >> instead. That would be a more direct way of nudging people to use SSL. >> It would cause a lot of breakage, but it would also be a big improvement >> to security. >> >> Consider how sslnegotiation=requiredirect/directonly would feel, if we >> made sslmode=require the default. If you explicitly set "sslmode=prefer" >> or "sslmode=disable", it would be annoying if you would also need to >> remove "sslnegotiation=requiredirect" from your connection string. > > That's similar to how sslrootcert=system already works. To me, it > feels great, because I don't have to worry about nonsensical > combinations (with the exception of GSS, which we've touched on > above). libpq complains loudly if I try to shoot myself in the foot, > and if I'm using sslrootcert=system then it's a pretty clear signal > that I care more about security than the temporary inconvenience of > editing my connection string for one weird server that doesn't use SSL > for some reason. Oh I was not aware sslrootcert=system works like that. That's a bit surprising, none of the other ssl-related settings imply or require that SSL is actually used. Did we intend to set a precedence for new settings with that? (adding Daniel in case he has an opinion) -- 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