MIME-Version: 1.0
References: <ZiH7vHwEJeRKHlST@paquier.xyz> <CAOYmi+kbYPX78nu0k7OODxUhoD6H1OXdugiMK1z9Nn33G-qdcQ@mail.gmail.com>
 <a0983295-67ae-487e-84e3-6e1148af3a25@iki.fi> <ZiYPmUZjcQtPz2j7@paquier.xyz>
 <feebbeee-df5f-484f-b07e-062bd0230bd2@iki.fi> <ZidKMB1tcgM3bzFZ@paquier.xyz>
 <CAOYmi+n57x+8DVi9J+dGmFQo+2Eb+bg_+geH=jqfh3E=NWHfOA@mail.gmail.com>
 <CA+TgmoaLpDVY2ywqQUfxvKEQZ+nwkabcw_f=i4Zyivt9CLjcmA@mail.gmail.com>
 <CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com>
 <5a79ed71-b365-4b20-80bc-9c2bf97bf84b@iki.fi> <CAOYmi+kfsRfopQRTuJwpsO50Urq=-gwYDJ1fWNkDr3oYM1wdjA@mail.gmail.com>
 <CA+TgmoZspODpL6AYbANpffhbF+Q12xo1pHXrR9ZSkYfEQWpP3w@mail.gmail.com>
 <CAOYmi+k3x-aKiVzyLfzdxFdmcBmVD8UvcwfB075BkNqyA1aa9w@mail.gmail.com>
 <CA+TgmobR1R8q-rT06oWdLw_Kp_i67Uey9b+rWVrrpCJVSDNBFQ@mail.gmail.com>
 <CAOYmi+=TB8=yfXoBk=p0k0GPaCD79F8xXcypZFkjKmPKuT0hjQ@mail.gmail.com>
 <f6833e88-2e21-459d-a661-152ced273c60@iki.fi> <CAOYmi+nWKJNihuMpT+ZVTC5-d+pQdACTK7xKhhwAB075EHrOMg@mail.gmail.com>
 <3a6f126c-e1aa-4dcc-9252-9868308f6cf0@iki.fi>
In-Reply-To: <3a6f126c-e1aa-4dcc-9252-9868308f6cf0@iki.fi>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Mon, 29 Apr 2024 11:43:04 -0700
Message-ID: <CAOYmi+k2kJcJLMj=K4Vb3S_J6tN6989Wfi5+amqf15VkHcej3Q@mail.gmail.com>
Subject: Re: Direct SSL connection with ALPN and HBA rules
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, 
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2Bk2kJcJLMj%3DK4Vb3S_J6tN6989Wfi5%2Bamqf15VkHcej3Q%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 29, 2024 at 1:38=E2=80=AFAM Heikki Linnakangas <hlinnaka@iki.fi=
> wrote:
> Sure, we'd try to fix them ASAP. But we've had the SSLRequest
> negotiation since time immemorial. If a new vulnerability is found, it's
> unlikely that we'd need to disable the SSLRequest negotiation altogether
> to fix it. We'd be in serious trouble with back-branches in that case.
> There's no sudden need to have a kill-switch for it.

I'm not really arguing that you'd need the kill switch to fix a
problem in the code. (At least, I'm not arguing that in this thread; I
reserve the right to argue that in the future. :D) But between the
point of time that a vulnerability is announced and a user has
upgraded, it's really nice to have a switch as a mitigation. Even
better if it's server-side, because then the DBA can protect all their
clients without requiring action on their part.

> Taking that to the extreme, you could argue for a kill-switch for every
> feature, just in case there's a vulnerability in them. I agree that
> authentication is more sensitive so reducing the surface of that is more
> reasonable. And but nevertheless.

I mean... that would be extreme, yeah. I don't think anyone's proposed that=
.

> If you only
> have v17 servers in your environment, so you know all servers support
> direct negotiation if they support SSL at all, but a mix of servers with
> and without SSL, sslnegotiation=3Ddirectonly would reduce roundtrips with
> sslmode=3Dprefer.

But if you're in that situation, what does the use of directonly give
you over `sslnegotiation=3Ddirect`? You already know that servers
support direct, so there's no additional performance penalty from the
less strict mode.

> Making requiredirect to imply sslmode=3Drequire, or error out unless you
> also set sslmode=3Drequire, feels like a cavalier way of forcing SSL. We
> should have a serious discussion on making sslmode=3Drequire the default
> instead. That would be a more direct way of nudging people to use SSL.
> It would cause a lot of breakage, but it would also be a big improvement
> to security.
>
> Consider how sslnegotiation=3Drequiredirect/directonly would feel, if we
> made sslmode=3Drequire the default. If you explicitly set "sslmode=3Dpref=
er"
> or "sslmode=3Ddisable", it would be annoying if you would also need to
> remove "sslnegotiation=3Drequiredirect" from your connection string.

That's similar to how sslrootcert=3Dsystem already works. To me, it
feels great, because I don't have to worry about nonsensical
combinations (with the exception of GSS, which we've touched on
above). libpq complains loudly if I try to shoot myself in the foot,
and if I'm using sslrootcert=3Dsystem then it's a pretty clear signal
that I care more about security than the temporary inconvenience of
editing my connection string for one weird server that doesn't use SSL
for some reason.

> I think the best way forward for those is something like a new
> "require_proto" parameter that you suggested upthread. Perhaps call it
> "encryption", with options "none", "ssl", "gss" so that you can provide
> multiple options and libpq will try them in the order specified. For
> example:
>
> encryption=3Dnone
> encryption=3Dssl, none  # like sslmode=3Dprefer
> encryption=3Dgss
> encryption=3Dgss, ssl   # try GSS first, then SSL
> encryption=3Dssl, gss   # try SSL first, then GSS
>
> This would make gssencmode and sslmode=3Ddisable/allow/prefer/require
> settings obsolete. sslmode would stil be needed to distinguish between
> verify-ca/verify-full though. But sslnegotiation would be still
> orthogonal to that.

I will give this some more thought.

Thanks,
--Jacob