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

From: "Magnus Hagander" <magnus(at)hagander(dot)net>
To: "Lou Picciano" <loupicciano(at)comcast(dot)net>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Srinivas Aji" <srinivas(dot)aji(at)emc(dot)com>
Sent: Friday, September 23, 2011 8:38:00 AM
Subject: Re: [HACKERS] 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(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.

Again, if you were soliciting votes, I'd take the aggressive stance: +1 for the backport to 9.1.

Of the population using SSL, you'd be pulling out the subset getting all the way down into PKI implementation, then, those actually doing apps teasing out these differences in verification behavior... Among _that_ group, you're only concerned with recent adopters of 9.1, and only those who wouldn't be in a position to adapt pretty quickly. Probably a pretty small cohort for something this esoteric.

In our case, we do run into it - for our new clients. We find ourselves in something of a support role regarding pqlib's SSL capabilities!

Lou Picciano