Re: Direct SSL connection with ALPN and HBA rules - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Direct SSL connection with ALPN and HBA rules
Date
Msg-id CAGECzQT8r3OGck0vOxPqhBK-SHba1fCwrFGOT3JBFHs=uPeZfA@mail.gmail.com
Whole thread Raw
In response to Re: Direct SSL connection with ALPN and HBA rules  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Direct SSL connection with ALPN and HBA rules
List pgsql-hackers
On Mon, 13 May 2024 at 18:14, Robert Haas <robertmhaas@gmail.com> wrote:
> I disagree with Jacob's assertion that sslmode=require has no security
> benefits over sslmode=prefer. That seems like the kind of pessimism
> that makes people hate security professionals. There have got to be
> some attacks that are foreclosed by encrypting the connection, even if
> you don't stop MITM attacks or other things that are more
> sophisticated than running wireshark and seeing what goes by on the
> wire.

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).



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix out-of-bounds in the function GetCommandTagName
Next
From: Antonin Houska
Date:
Subject: Re: UniqueKey v2