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 f6833e88-2e21-459d-a661-152ced273c60@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
Re: Direct SSL connection with ALPN and HBA rules
List pgsql-hackers
On 25/04/2024 21:13, Jacob Champion wrote:
> On Thu, Apr 25, 2024 at 10:35 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> Maybe I'm missing something here, but why doesn't sslnegotiation
>> override sslmode completely? Or alternatively, why not remove
>> sslnegotiation entirely and just have more sslmode values? I mean
>> maybe this shouldn't happen categorically, but if I say I want to
>> require a direct SSL connection, to me that implies that I don't want
>> an indirect SSL connection, and I really don't want a non-SSL
>> connection.

My thinking with sslnegotiation is that it controls how SSL is 
negotiated with the server, if SSL is to be used at all. It does not 
control whether SSL is used or required; that's what sslmode is for.

> I think that comes down to the debate upthread, and whether you think
> it's a performance tweak or a security feature. My take on it is,
> `direct` mode is performance, and `requiredirect` is security.

Agreed, although the the security benefits from `requiredirect` are 
pretty vague. It reduces the attack surface, but there are no known 
issues with the 'postgres' or 'direct' negotiation either.

Perhaps 'requiredirect' should be renamed to 'directonly'?

> (Especially since, with the current implementation, requiredirect can
> slow things down?)

Yes: the case is gssencmode=prefer, kerberos credentical cache present 
in client, and server doesn't support GSS. With 
sslnegotiation='postgres' or 'direct', libpq can do the SSL negotiation 
over the same TCP connection after the server rejected the GSSRequest. 
With sslnegotiation='requiredirect', it needs to open a new TCP connection.

> >> I think it's pretty questionable in 2024 whether sslmode=allow and
>> sslmode=prefer make any sense at all. I don't think it would be crazy
>> to remove them entirely. But I certainly don't think that they should
>> be allowed to bleed into the behavior of new, higher-security
>> configurations. Surely if I say I want direct SSL, it's that or
>> nothing, right?
> 
> I agree, but I more or less lost the battle at [1]. Like Matthias
> mentioned in [2]:
> 
>> I'm not sure about this either. The 'gssencmode' option is already
>> quite weird in that it seems to override the "require"d priority of
>> "sslmode=require", which it IMO really shouldn't.

Yeah, that combination is weird. I think we should forbid it. But that's 
separate from sslnegotiation.

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




pgsql-hackers by date:

Previous
From: Isaac Morland
Date:
Subject: Re: Why don't we support external input/output functions for the composite types
Next
From: Tom Lane
Date:
Subject: Re: Why don't we support external input/output functions for the composite types