On Mon, May 13, 2024 at 9:13 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I find this idea to be a massive improvement over the status quo,
+1
> and
> I didn't spot any major problems when I read through the patch,
> either.
Definitely not a major problem, but I think
select_next_encryption_method() has gone stale, since it originally
provided generality and lines of fallback that no longer exist. In
other words, I think the following code is now misleading:
> if (conn->sslmode[0] == 'a')
> SELECT_NEXT_METHOD(ENC_PLAINTEXT);
>
> SELECT_NEXT_METHOD(ENC_NEGOTIATED_SSL);
> SELECT_NEXT_METHOD(ENC_DIRECT_SSL);
>
> if (conn->sslmode[0] != 'a')
> SELECT_NEXT_METHOD(ENC_PLAINTEXT);
To me, that implies that negotiated mode takes precedence over direct,
but the point of the patch is that it's not possible to have both. And
if direct SSL is in use, then sslmode can't be "allow" anyway, and we
definitely don't want ENC_PLAINTEXT.
So if someone proposes a change to select_next_encryption_method(),
you'll have to remember to stare at init_allowed_encryption_methods()
as well, and think really hard about what's going on. And vice-versa.
That worries me.
> I don't have a strong opinion about whether sslnegotiation=direct
> should error out (as you propose here) or silently promote sslmode to
> require. I think either is defensible.
I'm comforted that, since sslrootcert=system already does it, plenty
of use cases will get that for free. And if you decide in the future
that you really really want it to promote, it won't be a compatibility
break to make that change. (That gives us more time for wider v16-17
adoption, to see how the sslrootcert=system magic promotion behavior
is going in practice.)
> Had I been implementing it, I
> think I would have done as Jacob proposes, just because once we've
> forced a direct SSL negotiation surely the only sensible behavior is
> to be using SSL, unless you think there should be a
> silently-reconnect-without-SSL behavior, which I sure don't.
We still allow GSS to preempt SSL, though, so "forced" is probably
overstating things.
> It's really hard to believe in 2024 that anyone should ever be using a
> setting that may or may not encrypt the connection. There's http and
> https but there's no httpmaybes.
+1. I think (someone hop in and correct me please) that Opportunistic
Encryption for HTTP mostly fizzled, and they gave it a *lot* of
thought.
--Jacob