Message-ID: <f6833e88-2e21-459d-a661-152ced273c60@iki.fi>
Date: Fri, 26 Apr 2024 00:50:33 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Direct SSL connection with ALPN and HBA rules
To: Jacob Champion <jacob.champion@enterprisedb.com>,
 Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: <ZiH7vHwEJeRKHlST@paquier.xyz>
 <c786e226-4039-4522-ba07-92501fce9b6a@iki.fi>
 <CAOYmi+kbYPX78nu0k7OODxUhoD6H1OXdugiMK1z9Nn33G-qdcQ@mail.gmail.com>
 <a0983295-67ae-487e-84e3-6e1148af3a25@iki.fi> <ZiYPmUZjcQtPz2j7@paquier.xyz>
 <feebbeee-df5f-484f-b07e-062bd0230bd2@iki.fi> <ZidKMB1tcgM3bzFZ@paquier.xyz>
 <CAOYmi+n57x+8DVi9J+dGmFQo+2Eb+bg_+geH=jqfh3E=NWHfOA@mail.gmail.com>
 <CA+TgmoaLpDVY2ywqQUfxvKEQZ+nwkabcw_f=i4Zyivt9CLjcmA@mail.gmail.com>
 <CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com>
 <5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi>
 <CAOYmi+kfsRfopQRTuJwpsO50Urq=-gwYDJ1fWNkDr3oYM1wdjA@mail.gmail.com>
 <CA+TgmoZspODpL6AYbANpffhbF+Q12xo1pHXrR9ZSkYfEQWpP3w@mail.gmail.com>
 <CAOYmi+k3x-aKiVzyLfzdxFdmcBmVD8UvcwfB075BkNqyA1aa9w@mail.gmail.com>
 <CA+TgmobR1R8q-rT06oWdLw_Kp_i67Uey9b+rWVrrpCJVSDNBFQ@mail.gmail.com>
 <CAOYmi+=TB8=yfXoBk=p0k0GPaCD79F8xXcypZFkjKmPKuT0hjQ@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <CAOYmi+=TB8=yfXoBk=p0k0GPaCD79F8xXcypZFkjKmPKuT0hjQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/f6833e88-2e21-459d-a661-152ced273c60%40iki.fi>
Precedence: bulk

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)