Tom Lane <t...@sss.pgh.pa.us> writes: > Robbie Harwood <rharw...@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 tampering makes the attempt at encryption useless; rather, it still foils a passive adversary, even if it doesn't do anything against an active one.
signature.asc
Description: PGP signature
