On Thu, Apr 25, 2024 at 12:28 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> On Thu, Apr 25, 2024 at 9:17 AM Robert Haas <robertmhaas@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