Re: Direct SSL connection with ALPN and HBA rules

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Direct SSL connection with ALPN and HBA rules
Date: 2024-04-23 21:19:57
Message-ID: 5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23/04/2024 22:33, Jacob Champion wrote:
> On Tue, Apr 23, 2024 at 10:43 AM Robert Haas <robertmhaas(at)gmail(dot)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?

You're right, the comment is wrong about sslmode=allow. There is no
negotiation of a plaintext connection, the client just sends the startup
packet directly. The HBA rules can reject it, but the client will have
to disconnect and reconnect in that case.

The documentation and that comment are misleading about failed GSSAPI
encryption too, and I also misremembered that. With
sslnegotiation=requiredirect, libpq never uses negotiated SSL mode. It
will reconnect after a rejected GSSAPI request. So that comment applies
to sslnegotiation=direct, but not sslnegotiation=requiredirect.

Attached patch tries to fix and clarify those.

(Note that the client will only attempt GSSAPI encryption if it can find
kerberos credentials in the environment.)

--
Heikki Linnakangas
Neon (https://neon.tech)

Attachment Content-Type Size
0001-Fix-documentation-and-comments-on-what-happens-after.patch text/x-patch 3.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-04-23 22:00:01 Re: GUC-ify walsender MAX_SEND_SIZE constant
Previous Message Daniel Gustafsson 2024-04-23 20:08:13 Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?