Tom Lane <tgl@sss.pgh.pa.us> writes:
> Robbie Harwood <rharwood@redhat.com> writes:
>> So there's a connection setting `sslmode` that we'll want something
>> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
>> think we only need three for GSSAPI: "disable", "allow", and "prefer"
>> (which presumably would be the default).
>
> FWIW, there is quite a bit of unhappiness around sslmode=prefer, see
> for example this thread:
> https://www.postgresql.org/message-id/flat/2A5EFBDC-41C6-42A8-8B6D-E69DA60E9962%40eggerapps.at
>
> I do not know if we can come up with a better answer, but I'd caution
> you against thinking that that's a problem-free model to emulate.
Understood. We have the slight simplification for GSSAPI of having
mutual authentication always (i.e., no need to worry about
unauthenticated-but-encrypted connections).
My personal view is that we want to try for as much security as we can
without breaking anything [0]. If a user knows that they want a specific
security, they can set "require"; if they don't want it, they can set
"disable". Setting "require" as the default breaks one class of users;
setting "disable" another. And I don't think we can punt the problem to
the user and make it a mandatory parameter, either.
I'm absolutely open to suggestions for how we could do better here,
especially since we're adding support for something new, but having read
the thread you mention I don't immediately see a superior design.
0: For what it's worth, I also don't agree with the assertion that having the ability to fallback to plaintext from
tamperingmakes the attempt at encryption useless; rather, it still foils a passive adversary, even if it doesn't do
anythingagainst an active one.