Re: Possible SSL improvements for a newcomer to tackle

From: Zeus Kronion <zkronion(at)gmail(dot)com>
To: Nico Williams <nico(at)cryptonector(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible SSL improvements for a newcomer to tackle
Date: 2017-10-04 13:09:44
Message-ID: CAA0N8QgF68=oVHF=AykP19=Psks8_2oU-n33tR5vC_BEH3fA9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 3, 2017 at 11:39 AM, Nico Williams <nico(at)cryptonector(dot)com>
wrote:

> On Tue, Oct 03, 2017 at 12:33:00AM -0400, Tom Lane wrote:
> > 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.
>
> 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.

I agree with Nico. If the server certificate can't be validated, the client
should fail to connect unless specifically opting out of MITM protection.
Why not change DefaultSSLMode from "prefer," even if it isn't backwards
compatible? Is there a policy for deprecating default settings?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-10-04 13:46:05 Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Previous Message Alexander Kuzmenkov 2017-10-04 13:08:41 Re: PoC: full merge join on comparison clause