Re: Direct SSL connection with ALPN and HBA rules

On 26/04/2024 02:23, Jacob Champion wrote:
> On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>> 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.
>
> I think reduction in attack surface is a concrete security benefit,
> not a vague one. True, I don't know of any exploits today, but that
> seems almost tautological -- if there were known exploits in our
> upgrade handshake, I assume we'd be working to fix them ASAP?

Sure, we'd try to fix them ASAP. But we've had the SSLRequest
negotiation since time immemorial. If a new vulnerability is found, it's
unlikely that we'd need to disable the SSLRequest negotiation altogether
to fix it. We'd be in serious trouble with back-branches in that case.
There's no sudden need to have a kill-switch for it.

Taking that to the extreme, you could argue for a kill-switch for every
feature, just in case there's a vulnerability in them. I agree that
authentication is more sensitive so reducing the surface of that is more
reasonable. And but nevertheless.

(This discussion is moot though, because we do have the
sslnegotiation=requiredirect mode, so you can disable the SSLRequest
negotiation.)

>> Perhaps 'requiredirect' should be renamed to 'directonly'?
>
> If it's agreed that we don't want to require a stronger sslmode for
> that sslnegotiation setting, then that would probably be an
> improvement. But who is the target user for
> `sslnegotiation=directonly`, in your opinion? Would they ever have a
> reason to use a weak sslmode?

It's unlikely, I agree. A user who's sophisticated enough to use
sslnegotiation=directonly would probably also want sslmode=require and
require_auth=scram-sha256 and channel_binding=require. Or
sslmode=verify-full. But in principle they're orthogonal. If you only
have v17 servers in your environment, so you know all servers support
direct negotiation if they support SSL at all, but a mix of servers with
and without SSL, sslnegotiation=directonly would reduce roundtrips with
sslmode=prefer.

Making requiredirect to imply sslmode=require, or error out unless you
also set sslmode=require, feels like a cavalier way of forcing SSL. We
should have a serious discussion on making sslmode=require the default
instead. That would be a more direct way of nudging people to use SSL.
It would cause a lot of breakage, but it would also be a big improvement
to security.

Consider how sslnegotiation=requiredirect/directonly would feel, if we
made sslmode=require the default. If you explicitly set "sslmode=prefer"
or "sslmode=disable", it would be annoying if you would also need to
remove "sslnegotiation=requiredirect" from your connection string.

I'm leaning towards renaming sslnegotiation=requiredirect to
sslnegotiation=directonly at this point.

>>>> 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.
>
> Separate but related, IMO. If we were all hypothetically okay with
> gssencmode ignoring `sslmode=require`, then it's hard for me to claim
> that `sslnegotiation=requiredirect` should behave differently. On the
> other hand, if we're not okay with that and we'd like to change it,
> it's easier for me to argue that `requiredirect` should also be
> stricter from the get-go.

I think the best way forward for those is something like a new
"require_proto" parameter that you suggested upthread. Perhaps call it
"encryption", with options "none", "ssl", "gss" so that you can provide
multiple options and libpq will try them in the order specified. For
example:

encryption=none
encryption=ssl, none # like sslmode=prefer
encryption=gss
encryption=gss, ssl # try GSS first, then SSL
encryption=ssl, gss # try SSL first, then GSS

This would make gssencmode and sslmode=disable/allow/prefer/require
settings obsolete. sslmode would stil be needed to distinguish between
verify-ca/verify-full though. But sslnegotiation would be still
orthogonal to that.

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