From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martin Pitt <mpitt(at)debian(dot)org>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt |
Date: | 2009-04-10 17:14:04 |
Message-ID: | 49DF7E5C.70003@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom Lane wrote:
> Martin Pitt <mpitt(at)debian(dot)org> writes:
>> I do see the benefit of failing to connect to an SSL-enabled server
>> *if* I have a root.crt which doesn't match. But why fail if I don't
>> have one?
>
> I think I agree with Martin on this. The server doesn't fail if you
> don't provide it a root cert; it just doesn't try to trace client certs
> to the root. It is not apparent why the client should be stricter than
> that, and definitely not apparent why such strictness should be the
> default behavior.
It's "secure by default". Without it, most people will *never* get
protected by verifying the certificate because they will not manually
copy root certificates there. And it would open up a big window for
making a very simple mistake (file missing or wrong name) that would
then silently disable SSL verification completely.
Arguably it's a bug to silently install a snakeoil cert by default. But
I realize that you have issues with backwards compatibility. How about
changing it so it points PGSSLROOTCERT to a system wide location that
holds the root.crt file? The user can then override this if proper
verification of a real certificate is wanted.
(you could also disable certificate verification by setting
PGSSLVERIFY=none, but that seems like a much worse fix)
//Mangus
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-10 17:17:56 | Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt |
Previous Message | Tom Lane | 2009-04-10 14:41:34 | Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt |