On Tue, Oct 03, 2017 at 12:33:00AM -0400, Tom Lane wrote:
> Zeus Kronion <zkronion@gmail.com> writes:
> > 2) I was surprised to learn the following from the docs:
>
> >> By default, PostgreSQL will not perform any verification of the server
> >> certificate.
>
> > Is there a technical reason to perform no verification by default? Wouldn't
> > a safer default be desirable?
>
> I'm not an SSL expert, so insert appropriate grain of salt, but AIUI the
> question is what are you going to verify against? You need some local
> notion of which are your trusted root certificates before you can verify
> anything. So to default to verification would be to default to failing to
> connect at all until user has created a ~/.postgresql/root.crt file with
> valid, relevant entries. That seems like a nonstarter.
>
> It's possible that we could adopt some policy like "if the root.crt file
> exists then default to verify" ... but that seems messy and unreliable,
> so I'm not sure it would really add any security.
You do always need trust anchors in order to verify a peer's
certificate.
Usually there will be a system-wide trust anchor set, though it may not
be appropriate for use with PG...
Still, it would be safer to refuse to connect until the lack of trust
anchors is rectified than to connect without warning about the inability
to verify a server. By forcing the user (admins) to take action to
remediate the problem, the problem then gets fixed, whereas plowing on
creates an invisible (for many users) security problem.
Now, the use of channel binding from authentication methods like GSS-API
helps a fair bit, though mostly it helps by leveraging some other
authentication infrastructure that the users (admins) have set up --
they could easily have setup PKI too then. With SCRAM there is much
less infrastructure (but also SCRAM requires very good passwords; a PAKE
would be much better).
Nico
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
