On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas <hlinn...@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
