MIME-Version: 1.0
References: <ZiH7vHwEJeRKHlST@paquier.xyz> <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> <CAOYmi+mAfO2hXfpOrpjhSZZf7Rq-rCywdyyfygkqbZ0KZjOBTg@mail.gmail.com>
 <d3b1608a-a1b6-4eda-9ec5-ddb3e4375808@iki.fi> <3fdaf4b1-82d1-45bb-8175-f97ff53a1f01@iki.fi>
 <CA+TgmoayZ5pBHqgfrYeZQ1dsubSLazq0CLfHM8m=dC1YrPL+UQ@mail.gmail.com> <CAGECzQT8r3OGck0vOxPqhBK-SHba1fCwrFGOT3JBFHs=uPeZfA@mail.gmail.com>
In-Reply-To: <CAGECzQT8r3OGck0vOxPqhBK-SHba1fCwrFGOT3JBFHs=uPeZfA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 13 May 2024 15:24:32 -0400
Message-ID: <CA+TgmoZ9Jujp3LE7Rbq7Ez5eNhKJ8zGKDcYBSz7_ynP44j=Cww@mail.gmail.com>
Subject: Re: Direct SSL connection with ALPN and HBA rules
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Jacob Champion <jacob.champion@enterprisedb.com>, 
	Daniel Gustafsson <daniel@yesql.se>, 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/CA%2BTgmoZ9Jujp3LE7Rbq7Ez5eNhKJ8zGKDcYBSz7_ynP44j%3DCww%40mail.gmail.com>
Precedence: bulk

On Mon, May 13, 2024 at 1:42=E2=80=AFPM Jelte Fennema-Nio <postgres@jeltef.=
nl> wrote:
> Like Jacob already said, I guess you meant me here. The main point I
> was trying to make is that sslmode=3Drequire is extremely insecure too,
> so if we're changing the default then I'd rather bite the bullet and
> actually make the default a secure one this time. No-ones browser
> trusts self-signed certs by default, but currently lots of people
> trust self-signed certs when connecting to their production database
> without realizing.
>
> IMHO the only benefit that sslmode=3Drequire brings over sslmode=3Dprefer
> is detecting incorrectly configured servers i.e. servers that are
> supposed to support ssl but somehow don't due to a misconfigured
> GUC/pg_hba. Such "incorrectly configured server" detection avoids
> sending data to such a server, which an eavesdropper on the network
> could see. Which is definitely a security benefit, but it's an
> extremely small one. In all other cases sslmode=3Dprefer brings exactly
> the same protection as sslmode=3Drequire, because sslmode=3Dprefer
> encrypts the connection unless postgres actively tells the client to
> downgrade to plaintext (which never happens when the server is
> configured correctly).

I think I agree with *nearly* every word of this. However:

(1) I don't want to hijack this thread about a v17 open item to talk
too much about a hypothetical v18 proposal.

(2) While in general you need more than just SSL to ensure security,
I'm not sure that there's only one way to do it, and I doubt that we
should try to pick a winner.

(3) I suspect that even going as far as sslmode=3Drequire by default is
going to be extremely painful for hackers, the project, and users.
Moving the goalposts further increases the likelihood of nothing
happening at all.

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