On Tue, Apr 23, 2024 at 10:43 AM Robert Haas <robertmh...@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
