MIME-Version: 1.0
References: <ZiH7vHwEJeRKHlST@paquier.xyz> <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> <CAOYmi+k2kJcJLMj=K4Vb3S_J6tN6989Wfi5+amqf15VkHcej3Q@mail.gmail.com>
 <1a717f65-7390-4111-8efd-c6e9b213805e@iki.fi>
In-Reply-To: <1a717f65-7390-4111-8efd-c6e9b213805e@iki.fi>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Mon, 29 Apr 2024 12:32:36 -0700
Message-ID: <CAOYmi+mAfO2hXfpOrpjhSZZf7Rq-rCywdyyfygkqbZ0KZjOBTg@mail.gmail.com>
Subject: Re: Direct SSL connection with ALPN and HBA rules
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Daniel Gustafsson <daniel@yesql.se>, 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%2BmAfO2hXfpOrpjhSZZf7Rq-rCywdyyfygkqbZ0KZjOBTg%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 29, 2024 at 12:06=E2=80=AFPM Heikki Linnakangas <hlinnaka@iki.f=
i> wrote:
> On 29/04/2024 21:43, Jacob Champion wrote:
> > 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.
>
> Well, by that argument we don't need requiredirect/directonly at all.
> This goes back to whether it's a security feature or a performance featur=
e.

That's what I've been trying to argue, yeah. If it's not a security
feature... why's it there?

> There is a small benefit with sslmode=3Dprefer if you connect to a server
> that doesn't support SSL, though. With sslnegotiation=3Ddirect, if the
> server rejects the direct SSL connection, the client will reconnect and
> try SSL with SSLRequest. The server will respond with 'N', and the
> client will proceed without encryption. sslnegotiation=3Ddirectonly
> removes that SSLRequest attempt, eliminating one roundtrip.

Okay, agreed that in this case, there is a performance benefit. It's
not enough to convince me, honestly, but are there any other cases I
missed as well?

> Oh I was not aware sslrootcert=3Dsystem works like that. That's a bit
> surprising, none of the other ssl-related settings imply or require that
> SSL is actually used.

For sslrootcert=3Dsystem in particular, the danger of accidentally weak
sslmodes is pretty high, especially for verify-ca mode. (It goes back
to that other argument -- there should be, effectively, zero users who
both opt in to the public CA system, and are also okay with silently
falling back and not using it.)

> Did we intend to set a precedence for new settings
> with that?

(I'll let committers answer whether they intended that or not -- I was
just bringing up that we already have a setting that works like that,
and I really like how it works in practice. But it's probably
unsurprising that I like it.)

--Jacob