Re: Re: [BUGS] BUG #6189: libpq: sslmode=require verifies server certificate if root.crt is present

On Fri, Sep 23, 2011 at 14:49, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Fri, Sep 23, 2011 at 14:35, Lou Picciano <loupicciano(at)comcast(dot)net> wrote:
>>> On Wed, Aug 31, 2011 at 11:59, Srinivas Aji <srinivas(dot)aji(at)emc(dot)com> wrote:
>>>>
>>>> The following bug has been logged online:
>>>>
>>>> Bug reference:      6189
>>>> Logged by:          Srinivas Aji
>>>> Email address:      srinivas(dot)aji(at)emc(dot)com
>>>> PostgreSQL version: 9.0.4
>>>> Operating system:   Linux
>>>> Description:        libpq: sslmode=require verifies server certificate if
>>>> root.crt is present
>>>> Details:
>>>>
>>> ...
>>>>
>>>> The observed behaviour is a bit different. If the ~/.postgresql/root.crt
>>>> file (or any other filename set through sslrootcert option) is found,
>>>> sslmode=require also performs the same level of certificate verification
>>>> as
>>>> verify-ca. The difference between require and verify-ca is that it is an
>>>> error for the file to not exist when sslmode is verify-ca.
>>>
>>> I looked at this again, and I'm pretty sure we did this intentionally.
>>> The idea being that before we had the verify-ca/verify-full options,
>>> adding the root cert would enable the verification. And we didn't want
>>> to turn installations that previously did verify the certificate to
>>> stop doing so in the new version.
>>>
>>> So basically, the behaviour that is by design is:
>>> * require: if certificate exists, verify. if certificate doesn't
>>> exist, don't verify.
>>> * verify-ca: if certificate exists, verify. if certificate doesn't
>>> exist, disconnect.
>>>
>>> The question is, have we had the new options long enough now that we
>>> should change it so that we don't verify the cert in the case of
>>> cert-exists-but-verification-wasn't-explicitly-asked-for?
>>>
>>> Or should we just update the documentation to mention how this works?
>>>
>>> Magnus, If you're accepting votes on this: I would say 'yes' - change the
>>> behavior to the most logically consistent ones; ie, isolate the verification
>>> bits a bit more explicitly. And, in documentation, indicate the deprecation
>>> of the old behavior.
>>>
>>> Our mileage, in practical terms, is that the perceived inconsistencies
>>> create a minor support hassle - we don't want to present any - even trivial
>>> - hurdle to adoption of SSL to our clients.
>>
>> There are really two options to this as well - we can backpatch such a
>> change, or we can change it only in 9.2. I'm leaning towards a "no" on
>> the backport, because that will change things for existing users. So
>> probably a doc change in backbranches and a behaviour change in 9.2
>> would be the reasonable choice in this case.
>
> I definitely don't think we should back-patch a behavior change that
> silently weakens security.  That's not good.
>
> But what about not doing it in master, either?  It seems to me that we
> could avoid ever breaking backward compatibility by adding a new
> option "require-no-verify".

Hmm. Intersting. and we could then deprecate the "require" option and
kill it off 4 releases later or so, I guess...

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