On 29/04/2024 22:32, Jacob Champion wrote:
On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas <hlinn...@iki.fi> wrote:
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.
Okay, agreed that in this case, there is a performance benefit. It's
not enough to convince me, honestly, but are there any other cases I
missed as well?
I realized one case that hasn't been discussed so far: If you use the
combination of "sslmode=prefer sslnegotiation=requiredirect" to connect
to a pre-v17 server that has SSL enabled but does not support direct SSL
connections, you will fall back to a plaintext connection instead.
That's almost certainly not what you wanted. I'm coming around to your
opinion that we should not allow that combination.
Stepping back to summarize my thoughts, there are now three things I
don't like about the status quo:
1. As noted above, the sslmode=prefer and sslnegotiation=requiredirect
combination is somewhat dangerous, as you might unintentionally fall
back to plaintext authentication when connecting to a pre-v17 server.
2. There is an asymmetry between "postgres" and "direct"
option names. "postgres" means "try only traditional negotiation", while
"direct" means "try direct first, and fall back to traditional
negotiation if it fails". That is apparent only if you know that the
"requiredirect" mode also exists.
3. The "require" word in "requiredirect" suggests that it's somehow
more strict or more secure, similar to sslmode=require. However, I don't
consider direct SSL connections to be a security feature.
New proposal:
- Remove the "try both" mode completely, and rename "requiredirect" to
just "direct". So there would be just two modes: "postgres" and
"direct". On reflection, the automatic fallback mode doesn't seem very
useful. It would make sense as the default, because then you would get
the benefits automatically in most cases but still be compatible with
old servers. But if it's not the default, you have to fiddle with libpq
settings anyway to enable it, and then you might as well use the
"requiredirect" mode when you know the server supports it. There isn't
anything wrong with it as such, but given how much confusion there's
been on how this all works, I'd prefer to cut this back to the bare
minimum now. We can add it back in the future, and perhaps make it the
default at the same time. This addresses points 2. and 3. above.
and:
- Only allow sslnegotiation=direct with sslmode=require or higher. This
is what you, Jacob, wanted to do all along, and addresses point 1.
Thoughts?
--
Heikki Linnakangas
Neon (https://neon.tech)
