Re: Direct SSL connection with ALPN and HBA rules

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)