On Mon, May 13, 2024 at 1:42 PM 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=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