public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Direct SSL connection with ALPN and HBA rules
Date: Mon, 13 May 2024 15:24:32 -0400
Message-ID: <CA+TgmoZ9Jujp3LE7Rbq7Ez5eNhKJ8zGKDcYBSz7_ynP44j=Cww@mail.gmail.com> (raw)
In-Reply-To: <CAGECzQT8r3OGck0vOxPqhBK-SHba1fCwrFGOT3JBFHs=uPeZfA@mail.gmail.com>
References: <[email protected]>
<CA+TgmoaLpDVY2ywqQUfxvKEQZ+nwkabcw_f=i4Zyivt9CLjcmA@mail.gmail.com>
<CAOYmi+=sj+1uydS0NR4nYzw-LRWp3Q-s5speBug5UCLSPMbvGA@mail.gmail.com>
<[email protected]>
<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>
<[email protected]>
<CAOYmi+nWKJNihuMpT+ZVTC5-d+pQdACTK7xKhhwAB075EHrOMg@mail.gmail.com>
<[email protected]>
<CAOYmi+k2kJcJLMj=K4Vb3S_J6tN6989Wfi5+amqf15VkHcej3Q@mail.gmail.com>
<[email protected]>
<CAOYmi+mAfO2hXfpOrpjhSZZf7Rq-rCywdyyfygkqbZ0KZjOBTg@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmoayZ5pBHqgfrYeZQ1dsubSLazq0CLfHM8m=dC1YrPL+UQ@mail.gmail.com>
<CAGECzQT8r3OGck0vOxPqhBK-SHba1fCwrFGOT3JBFHs=uPeZfA@mail.gmail.com>
On Mon, May 13, 2024 at 1:42 PM Jelte Fennema-Nio <[email protected]> wrote:
> Like Jacob already said, I guess you meant me here. The main point I
> was trying to make is that sslmode=require 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=require brings over sslmode=prefer
> 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=prefer brings exactly
> the same protection as sslmode=require, because sslmode=prefer
> 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=require 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
view thread (30+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Direct SSL connection with ALPN and HBA rules
In-Reply-To: <CA+TgmoZ9Jujp3LE7Rbq7Ez5eNhKJ8zGKDcYBSz7_ynP44j=Cww@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox