On Tue, Apr 23, 2024 at 10:43 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I've not followed this thread closely enough to understand the comment
> about requiredirect maybe not actually requiring direct, but if that
> were true it seems like it might be concerning.
It may be my misunderstanding. This seems to imply bad behavior:
> If the server rejects GSS encryption, SSL is
> negotiated over the same TCP connection using the traditional postgres
> protocol, regardless of <literal>sslnegotiation</literal>.
As does this comment:
> + /*
> + * If enabled, try direct SSL. Unless we have a valid TCP connection that
> + * failed negotiating GSSAPI encryption or a plaintext connection in case
> + * of sslmode='allow'; in that case we prefer to reuse the connection with
> + * negotiated SSL, instead of reconnecting to do direct SSL. The point of
> + * direct SSL is to avoid the roundtrip from the negotiation, but
> + * reconnecting would also incur a roundtrip.
> + */
but when I actually try those cases, I see that requiredirect does
actually cause a direct SSL connection to be done, even with
sslmode=allow. So maybe it's just misleading documentation (or my
misreading of it) that needs to be expanded? Am I missing a different
corner case where requiredirect is ignored, Heikki?
I still question the utility of allowing sslmode=allow with
sslnegotiation=requiredirect, because it seems like you've made both
the performance and security characteristics actively worse if you
choose that combination. But I want to make sure I understand the
current behavior correctly before I derail the discussion too much...
Thanks,
--Jacob