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

On Fri, Sep 23, 2011 at 14:35, Lou Picciano <loupicciano@comcast.net> wrote:
>
> On Wed, Aug 31, 2011 at 11:59, Srinivas Aji <srinivas.aji@emc.com> wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference:      6189
>> Logged by:          Srinivas Aji
>> Email address:      srinivas.aji@emc.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.


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