On Thu, Apr 25, 2024 at 12:28 PM Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > On Thu, Apr 25, 2024 at 9:17 AM Robert Haas <robertmh...@gmail.com> wrote: > > It is difficult to imagine a world in which we have both requiredirect > > and forcedirect and people are not confused. > > Yeah... Any thoughts on a better scheme? require_auth was meant to > lock down overly general authentication; maybe a require_proto or > something could do the same for the transport?
I don't understand the difference between the two sets of semantics myself, so I'm not in a good position to comment. > I hate that we have so many options that most people don't need but > take precedence, especially when they're based on the existence of > magic third-party environmental cues (e.g. Kerberos caches). And it > was nice that we got sslrootcert=system to turn on strong security and > reject nonsensical combinations. If someone sets `requiredirect` and > leaves the default sslmode, or chooses a weaker one... Is that really > useful to someone? Maybe I'm missing something here, but why doesn't sslnegotiation override sslmode completely? Or alternatively, why not remove sslnegotiation entirely and just have more sslmode values? I mean maybe this shouldn't happen categorically, but if I say I want to require a direct SSL connection, to me that implies that I don't want an indirect SSL connection, and I really don't want a non-SSL connection. I think it's pretty questionable in 2024 whether sslmode=allow and sslmode=prefer make any sense at all. I don't think it would be crazy to remove them entirely. But I certainly don't think that they should be allowed to bleed into the behavior of new, higher-security configurations. Surely if I say I want direct SSL, it's that or nothing, right? -- Robert Haas EDB: http://www.enterprisedb.com
