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?
> 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?
> >> 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.
Thanks,
--Jacob