Re: Direct SSL connection with ALPN and HBA rules - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Direct SSL connection with ALPN and HBA rules
Date
Msg-id 5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi
Whole thread Raw
In response to Re: Direct SSL connection with ALPN and HBA rules  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: Direct SSL connection with ALPN and HBA rules
List pgsql-hackers
On 23/04/2024 22:33, Jacob Champion wrote:
> 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?

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

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Next
From: Andres Freund
Date:
Subject: Re: GUC-ify walsender MAX_SEND_SIZE constant