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-25 21:50:33
Message-ID: f6833e88-2e21-459d-a661-152ced273c60@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25/04/2024 21:13, Jacob Champion wrote:
> On Thu, Apr 25, 2024 at 10:35 AM Robert Haas <robertmhaas(at)gmail(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-25 21:51:35 Re: Why don't we support external input/output functions for the composite types
Previous Message Isaac Morland 2024-04-25 21:39:17 Re: Why don't we support external input/output functions for the composite types