On Wed, Aug 31, 2011 at 09:59:18AM +0000, Srinivas Aji 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:
From the documentation of sslmode values in
http://www.postgresql.org/docs/9.0/static/libpq-ssl.html ,
it looks like libpq will not verify the server certificate when the option
sslmode=require is used, and will perform different levels of certificate
verification in the cases sslmode=verify-ca and sslmode=verify-full.

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.

Thanks,
Srinivas
It looks to me like there could at least in theory be an attack vector
or two that we're not covering with this bug. Anybody want to tackle
same?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Search Discussions

  • Magnus Hagander at Sep 12, 2011 at 5:37 pm

    On Mon, Sep 12, 2011 at 19:21, David Fetter wrote:
    On Wed, Aug 31, 2011 at 09:59:18AM +0000, Srinivas Aji 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:
    From the documentation of sslmode values in
    http://www.postgresql.org/docs/9.0/static/libpq-ssl.html ,
    it looks like libpq will not verify the server certificate when the option
    sslmode=require is used, and will perform different levels of certificate
    verification in the cases sslmode=verify-ca and sslmode=verify-full.

    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.

    Thanks,
    Srinivas
    It looks to me like there could at least in theory be an attack vector
    or two that we're not covering with this bug.  Anybody want to tackle
    same?
    I haven't checked the code yet, but from the report it sounds like
    we're checking *too much* - how could that be an attack vector?
  • David Fetter at Sep 12, 2011 at 6:21 pm

    On Mon, Sep 12, 2011 at 07:37:23PM +0200, Magnus Hagander wrote:
    On Mon, Sep 12, 2011 at 19:21, David Fetter wrote:
    On Wed, Aug 31, 2011 at 09:59:18AM +0000, Srinivas Aji 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:
    From the documentation of sslmode values in
    http://www.postgresql.org/docs/9.0/static/libpq-ssl.html ,
    it looks like libpq will not verify the server certificate when the option
    sslmode=require is used, and will perform different levels of certificate
    verification in the cases sslmode=verify-ca and sslmode=verify-full.

    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.

    Thanks,
    Srinivas
    It looks to me like there could at least in theory be an attack vector
    or two that we're not covering with this bug.  Anybody want to tackle
    same?
    I haven't checked the code yet, but from the report it sounds like
    we're checking *too much* - how could that be an attack vector?
    Well, "too much checking," classically, is a source of denial of
    service attacks. It's not a super likely source, but it's a source,
    and it'd be better to fix it than leave it lie. :)

    Cheers,
    David.
    --
    David Fetter <david@fetter.org> http://fetter.org/
    Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
    Skype: davidfetter XMPP: david.fetter@gmail.com
    iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

    Remember to vote!
    Consider donating to Postgres: http://www.postgresql.org/about/donate
  • Robert Haas at Sep 13, 2011 at 3:14 am

    On Mon, Sep 12, 2011 at 2:20 PM, David Fetter wrote:
    Well, "too much checking," classically, is a source of denial of
    service attacks.  It's not a super likely source, but it's a source,
    and it'd be better to fix it than leave it lie. :)
    You forgot to attach the patch.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • Magnus Hagander at Sep 23, 2011 at 11:28 am

    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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:

    From the documentation of sslmode values in
    http://www.postgresql.org/docs/9.0/static/libpq-ssl.html ,
    it looks like libpq will not verify the server certificate when the option
    sslmode=require is used, and will perform different levels of certificate
    verification in the cases sslmode=verify-ca and sslmode=verify-full.

    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?
  • Lou Picciano at Sep 23, 2011 at 12:35 pm
    From: "Magnus Hagander" <magnus@hagander.net>
    To: "Srinivas Aji" <srinivas.aji@emc.com>
    Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
    Sent: Friday, September 23, 2011 7:28:09 AM
    Subject: [HACKERS] Re: [BUGS] BUG #6189: libpq: sslmode=require verifies server certificate if root.crt is present
    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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 Hagander
    Me: http://www.hagander.net/
    Work: http://www.redpill-linpro.com/

    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.

    Lou Picciano
  • Magnus Hagander at Sep 23, 2011 at 12:38 pm

    On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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.
  • Robert Haas at Sep 23, 2011 at 12:49 pm

    On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander wrote:
    On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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.
    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".

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company
  • Magnus Hagander at Sep 23, 2011 at 1:39 pm

    On Fri, Sep 23, 2011 at 14:49, Robert Haas wrote:
    On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander wrote:
    On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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.
    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...
  • Alvaro Herrera at Sep 23, 2011 at 1:55 pm

    Excerpts from Magnus Hagander's message of vie sep 23 10:39:46 -0300 2011:
    On Fri, Sep 23, 2011 at 14:49, Robert Haas wrote:
    On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander wrote:
    On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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
    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.
    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...
    So we would have
    sslmode=verify-ca / require-no-verify / verify-full / disable / allow / prefer
    ?

    This seems strange to me. Why not have a second option to let the user
    indicate the desired SSL verification?

    sslmode=disable/allow/prefer/require
    sslverify=none/ca-if-present/ca/full

    (ca-if-present being the current "require" sslmode behavior).

    We could then deprecate sslmode=verify and verify-full and have them be
    synonyms of sslmode=require and corresponding sslverify.

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Magnus Hagander at Sep 23, 2011 at 2:31 pm

    On Fri, Sep 23, 2011 at 15:55, Alvaro Herrera wrote:

    Excerpts from Magnus Hagander's message of vie sep 23 10:39:46 -0300 2011:
    On Fri, Sep 23, 2011 at 14:49, Robert Haas wrote:
    On Fri, Sep 23, 2011 at 8:38 AM, Magnus Hagander wrote:
    On Fri, Sep 23, 2011 at 14:35, Lou Picciano wrote:
    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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
    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.
    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...
    So we would have
    sslmode=verify-ca / require-no-verify / verify-full / disable / allow / prefer
    ?

    This seems strange to me.  Why not have a second option to let the user
    indicate the desired SSL verification?

    sslmode=disable/allow/prefer/require
    sslverify=none/ca-if-present/ca/full

    (ca-if-present being the current "require" sslmode behavior).

    We could then deprecate sslmode=verify and verify-full and have them be
    synonyms of sslmode=require and corresponding sslverify.
    Hmm. I agree that the other suggestion was a bit weird, but I'm not
    sure I like the multiple-options approach either. That's going to
    require redesign of all software that deals with it at all today :S

    Maybe we should just update the docs and be done with it :-)
  • Alvaro Herrera at Sep 23, 2011 at 2:44 pm

    Excerpts from Magnus Hagander's message of vie sep 23 11:31:37 -0300 2011:

    On Fri, Sep 23, 2011 at 15:55, Alvaro Herrera
    wrote:
    This seems strange to me.  Why not have a second option to let the user
    indicate the desired SSL verification?

    sslmode=disable/allow/prefer/require
    sslverify=none/ca-if-present/ca/full

    (ca-if-present being the current "require" sslmode behavior).

    We could then deprecate sslmode=verify and verify-full and have them be
    synonyms of sslmode=require and corresponding sslverify.
    Hmm. I agree that the other suggestion was a bit weird, but I'm not
    sure I like the multiple-options approach either. That's going to
    require redesign of all software that deals with it at all today :S
    Why? They could continue to use the existing options; or switch to the
    new options if they wanted different behavior, as is the case of the OP.
    Maybe we should just update the docs and be done with it :-)
    That's another option, sure ... :-)

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Magnus Hagander at Sep 24, 2011 at 12:33 pm

    On Fri, Sep 23, 2011 at 16:44, Alvaro Herrera wrote:

    Excerpts from Magnus Hagander's message of vie sep 23 11:31:37 -0300 2011:
    On Fri, Sep 23, 2011 at 15:55, Alvaro Herrera
    wrote:
    This seems strange to me.  Why not have a second option to let the user
    indicate the desired SSL verification?

    sslmode=disable/allow/prefer/require
    sslverify=none/ca-if-present/ca/full

    (ca-if-present being the current "require" sslmode behavior).

    We could then deprecate sslmode=verify and verify-full and have them be
    synonyms of sslmode=require and corresponding sslverify.
    Hmm. I agree that the other suggestion was a bit weird, but I'm not
    sure I like the multiple-options approach either. That's going to
    require redesign of all software that deals with it at all today :S
    Why?  They could continue to use the existing options; or switch to the
    new options if they wanted different behavior, as is the case of the OP.
    I guess. I was mostly thinking in the terms of anything that has
    connection things that look anything like the one in pgadmin for
    example - which will now suddenly need more than one dropdown box, for
    what really should be a simple setting. But I guess that can be
    considered an UI thing, and jus thave said application map a single
    dropdown to multiple options in the connection string.

    Maybe we should just update the docs and be done with it :-)
    That's another option, sure ... :-)
    I've applied a docs fix for this now. We can keep discussing how to
    make a more extensive fix in head :)
  • Lou Picciano at Sep 23, 2011 at 1:01 pm
    From: "Magnus Hagander" <magnus@hagander.net>
    To: "Lou Picciano" <loupicciano@comcast.net>
    Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>, "Srinivas Aji" <srinivas.aji@emc.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 wrote:
    On Wed, Aug 31, 2011 at 11:59, Srinivas Aji 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.

    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
  • Tom Lane at Sep 23, 2011 at 12:56 pm

    Magnus Hagander writes:
    I looked at this again, and I'm pretty sure we did this intentionally.
    Yeah, we did.
    Or should we just update the documentation to mention how this works?
    +1 for doc change only. I think the behavior was thought through
    carefully, and the wording of the docs maybe not so much.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 12, '11 at 5:21p
activeSep 24, '11 at 12:33p
posts15
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase