Re: Possible SSL improvements for a newcomer to tackle

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zeus Kronion <zkronion(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible SSL improvements for a newcomer to tackle
Date: 2017-10-03 07:38:07
Message-ID: CABUevEx4Q8O8MhoxeDPNLo_jP31_gcN7qwJG+WGQ7+aKW_nzyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 3, 2017 at 6:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Zeus Kronion <zkronion(at)gmail(dot)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.
>

Yes, you need something to verify against.

One way to do it would be to default to the "system global certificate
store", which is what most other SSL apps do. For example on a typical
debian/ubuntu, that'd be the store in /etc/ssl/certs/ca-certificates.crt.
Exactly where to find them would be distribution-specific though, and we
would need to actually add support for a second certificate store. But that
would probably be a useful feature in itself.

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

No that's horrible. If it's unreliable, it doesn't provide any actual
benefit. We have a history of that in our default being prefer instead of
allow, but we definitely shouldn't make that situation even worse.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-10-03 07:55:22 Re: SendRowDescriptionMessage() is slow for queries with a lot of columns
Previous Message Vladimir Sitnikov 2017-10-03 07:30:00 Re: 64-bit queryId?