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@iki.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)