Re: Direct SSL connection with ALPN and HBA rules

On Mon, May 13, 2024 at 9:37 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 10/05/2024 16:50, Heikki Linnakangas wrote:
> > New proposal:
> >
> > - Remove the "try both" mode completely, and rename "requiredirect" to
> > just "direct". So there would be just two modes: "postgres" and
> > "direct". On reflection, the automatic fallback mode doesn't seem very
> > useful. It would make sense as the default, because then you would get
> > the benefits automatically in most cases but still be compatible with
> > old servers. But if it's not the default, you have to fiddle with libpq
> > settings anyway to enable it, and then you might as well use the
> > "requiredirect" mode when you know the server supports it. There isn't
> > anything wrong with it as such, but given how much confusion there's
> > been on how this all works, I'd prefer to cut this back to the bare
> > minimum now. We can add it back in the future, and perhaps make it the
> > default at the same time. This addresses points 2. and 3. above.
> >
> > and:
> >
> > - Only allow sslnegotiation=direct with sslmode=require or higher. This
> > is what you, Jacob, wanted to do all along, and addresses point 1.
>
> Here's a patch to implement that.

I find this idea to be a massive improvement over the status quo, and
I didn't spot any major problems when I read through the patch,
either. I'm not quite sure if the patch takes the right approach in
emphasizing that weaker sslmode settings are not allowed because of
unintended fallbacks. It seems to me that we could equally well say
that those combinations are nonsensical. If we're making a direct SSL
connection, SSL is eo ipso required.

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. 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. However,
I disagree with Jacob's assertion that sslmode=require has no security
benefits over sslmode=prefer. That seems like the kind of pessimism
that makes people hate security professionals. There have got to be
some attacks that are foreclosed by encrypting the connection, even if
you don't stop MITM attacks or other things that are more
sophisticated than running wireshark and seeing what goes by on the
wire.

I'm pleased to hear that you will propose to make sslmode=require the
default in v18. I think we'll need to do some work to figure out how
much collateral damage that will cause, and maybe it will be more than
we can stomach, but Magnus has been saying for years that the current
default is terrible. I'm not sure I was entirely convinced of that the
first time I heard him say it, but I'm smarter now than I was then.
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.

--
Robert Haas
EDB: http://www.enterprisedb.com