On Sat, Sep 21, 2019 at 11:24:30AM +0900, Michael Paquier wrote:
> And both make sense.
>
> + * Return true if channel binding was employed and the scram exchange
> upper('scram')?
>
> Except for this nit, it looks good to me.
For the archive's sake: this has been committed as of d6e612f.
- *
On Fri, Sep 20, 2019 at 10:57:04AM -0700, Jeff Davis wrote:
> Thank you, applied.
Okay, I can see which parts you have changed.
> * I also changed the comment above pg_fe_scram_channel_bound() to
> clarify that the caller must also check that the exchange was
> successful.
>
> * I changed the er
On Fri, 2019-09-20 at 13:07 +0900, Michael Paquier wrote:
> Those are mainly nits, and attached are the changes I would do to
> your
> patch. Please feel free to consider those changes as you see fit.
> Anyway, the base logic looks good to me, so I am switching the patch
> as ready for committer.
On Thu, Sep 19, 2019 at 05:40:15PM -0700, Jeff Davis wrote:
> On Tue, 2019-09-17 at 16:04 +0900, Michael Paquier wrote:
>> What do you think? There is no need to save down the connection
>> parameter value into fe_scram_state.
>
> I'm not sure I understand this comment, but I removed the extra bo
On Tue, 2019-09-17 at 16:04 +0900, Michael Paquier wrote:
> basically maps into checking after FE_SCRAM_FINISHED. Instead of
> those two flags, wouldn't it be cleaner to add an extra routine to
> fe-auth-scram.c which does the same sanity checks, say
> pg_fe_scram_check_state()? This needs to be
On Sat, Sep 14, 2019 at 08:42:53AM -0700, Jeff Davis wrote:
> On Fri, 2019-09-06 at 16:05 +0900, Michael Paquier wrote:
>> Actually, it looks that the handling of channel_bound is incorrect.
>> If the server sends AUTH_REQ_SASL and libpq processes it, then the
>> flag gets already set. Now let's i
On Fri, 2019-09-06 at 16:05 +0900, Michael Paquier wrote:
> Nit here: "scram-sha-256" refers to the HBA entry. I would
> just use "SCRAM" instead.
Done.
> In pg_SASL_init(), if the server sends SCRAM-SHA-256-PLUS as SASL
> mechanism over a non-SSL connection, should we complain even if
> the "di
On Wed, Sep 04, 2019 at 09:22:33PM -0700, Jeff Davis wrote:
> New patch attached.
Thanks for the new version, Jeff.
+with PostgreSQL 11 or later servers using
+the scram-sha-256 authentication method.
Nit here: "scram-sha-256" refers to the HBA entry. I would
just use "SCRAM" in
On Wed, 2019-08-21 at 16:12 +0900, Michael Paquier wrote:
> This counts for other auth requests as well like krb5, no? I think
> that we should also add the "disable" flavor for symmetry, and
> also...
Added "disable" option, and I refactored so that it would look
explicitly for an expected auth
On Tue, Aug 20, 2019 at 07:09:25PM -0700, Jeff Davis wrote:
> OK, new patch attached. Seems like everyone is in agreement that we
> need a channel_binding param.
+
+A setting of require means that the connection must
+employ channel binding; and that the client will not respo
On Mon, 2019-08-19 at 14:51 +0900, Michael Paquier wrote:
> On Fri, Aug 16, 2019 at 02:11:57PM -0400, Jonathan S. Katz wrote:
> > To be pedantic, +1 on the channel_binding param.
>
> Seems like we are moving in this direction then. I don't object to
> the introduction of this parameter.
OK, new
On Fri, Aug 16, 2019 at 02:11:57PM -0400, Jonathan S. Katz wrote:
> To be pedantic, +1 on the channel_binding param.
Seems like we are moving in this direction then. I don't object to
the introduction of this parameter. We would likely want to do
something for downgrade attacks in other cases wh
On 8/15/19 9:28 PM, Stephen Frost wrote:
> Greetings,
>
> * Jeff Davis (pg...@j-davis.com) wrote:
>> On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote:
>>> What I got in mind was a comma-separated list of authorized protocols
>>> which can be specified as a connection parameter, which exten
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote:
> > What I got in mind was a comma-separated list of authorized protocols
> > which can be specified as a connection parameter, which extends to
> > all
> > the types of AUTH_REQ requests
On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote:
> What I got in mind was a comma-separated list of authorized protocols
> which can be specified as a connection parameter, which extends to
> all
> the types of AUTH_REQ requests that libpq can understand, plus an
> extra for channel bindin
On Tue, Aug 13, 2019 at 04:51:57PM -0400, Jonathan S. Katz wrote:
> On 8/13/19 12:25 PM, Jeff Davis wrote:
>> On Tue, 2019-08-13 at 11:56 +0900, Michael Paquier wrote:
>>> I tend to prefer #2 as well and that's the kind of approach we were
>>> tending to agree on when we discussed this issue during
On 8/13/19 6:25 PM, Jeff Davis wrote:
> On Tue, 2019-08-13 at 16:51 -0400, Jonathan S. Katz wrote:
>> Alternatively, we could combine 2 & 3, e.g.:
>>
>> channel_binding = {disable|prefer|require}
>>
>> # comma-separated list of protocols that are ok to the user, remove
>> # ones you don't wan
On Tue, 2019-08-13 at 16:51 -0400, Jonathan S. Katz wrote:
> Alternatively, we could combine 2 & 3, e.g.:
>
> channel_binding = {disable|prefer|require}
>
> # comma-separated list of protocols that are ok to the user, remove
> # ones you don't want. empty means all is ok
> password_protoc
On 8/13/19 12:25 PM, Jeff Davis wrote:
> On Tue, 2019-08-13 at 11:56 +0900, Michael Paquier wrote:
>> I tend to prefer #2 as well and that's the kind of approach we were
>> tending to agree on when we discussed this issue during the v11 beta
>> for the downgrade issues with libpq. And as you say e
On Tue, 2019-08-13 at 11:56 +0900, Michael Paquier wrote:
> I tend to prefer #2 as well and that's the kind of approach we were
> tending to agree on when we discussed this issue during the v11 beta
> for the downgrade issues with libpq. And as you say extend it so as
> we can apply filtering of m
On Mon, Aug 12, 2019 at 07:05:08PM +0200, Peter Eisentraut wrote:
> In this context, I would prefer #2, but I would expand that to cover all
> authentication methods, not only password methods.
I tend to prefer #2 as well and that's the kind of approach we were
tending to agree on when we discusse
On Fri, Aug 09, 2019 at 09:28:50AM -0400, Stephen Frost wrote:
> I don't really care for auth_protocol as that's pretty close to
> "auth_method" and that isn't what we're talking about here- this isn't
> the user picking the auth method, per se, but rather saying which of the
> password-based mecha
On 2019-08-12 19:26, Tom Lane wrote:
> What problem do we actually need to solve here?
>
> If the known use-case is just "don't send my password in the clear",
> maybe we should just change libpq to refuse to do that, ie reject
> plain-password auth methods unless SSL is on (except maybe over
> un
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm not really thrilled with approach #2 because it means the user
> > will have to know which of the PG authentication methods involve, eg,
> > sending the password in the clear to the server, and which don't, if
> > w
Stephen Frost writes:
> I'm not really thrilled with approach #2 because it means the user
> will have to know which of the PG authentication methods involve, eg,
> sending the password in the clear to the server, and which don't, if
> what they're really looking for is "don't send my password in
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-08-12 18:02, Jeff Davis wrote:
> > https://postgr.es/m/daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel%40j-davis.com
> >
> > The weakness of proposal #1 is that it's not very "future-proof" and we
> > would likely ne
On 2019-08-12 18:02, Jeff Davis wrote:
> https://postgr.es/m/daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel%40j-davis.com
>
> The weakness of proposal #1 is that it's not very "future-proof" and we
> would likely need to change something about it later when we support
> new methods. That wouldn't
On Sun, 2019-08-11 at 19:00 +0200, Peter Eisentraut wrote:
> On 2019-08-09 23:56, Jeff Davis wrote:
> > 1. Hierarchical semantics, where you specify the least-secure
> > acceptable method:
> >
> > password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>
> What would the hierarchy be if
On 8/11/19 3:56 PM, Peter Eisentraut wrote:
> On 2019-08-11 21:46, Jonathan S. Katz wrote:
>> On 8/11/19 1:00 PM, Peter Eisentraut wrote:
>>> On 2019-08-09 23:56, Jeff Davis wrote:
1. Hierarchical semantics, where you specify the least-secure
acceptable method:
password_protoc
On 2019-08-11 21:46, Jonathan S. Katz wrote:
> On 8/11/19 1:00 PM, Peter Eisentraut wrote:
>> On 2019-08-09 23:56, Jeff Davis wrote:
>>> 1. Hierarchical semantics, where you specify the least-secure
>>> acceptable method:
>>>
>>> password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>>
>
On 8/11/19 1:00 PM, Peter Eisentraut wrote:
> On 2019-08-09 23:56, Jeff Davis wrote:
>> 1. Hierarchical semantics, where you specify the least-secure
>> acceptable method:
>>
>> password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>
> What would the hierarchy be if scram-sha-512 and sc
On 2019-08-09 23:56, Jeff Davis wrote:
> 1. Hierarchical semantics, where you specify the least-secure
> acceptable method:
>
> password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
What would the hierarchy be if scram-sha-512 and scram-sha-512-plus are
added?
--
Peter Eisentraut
On 8/9/19 7:54 PM, Jeff Davis wrote:
> On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:
>> This is a multi-dimensional problem. "channel_binding=require" is
>> one
>> way to prevent MITM attacks, but sslmode=verify-ca is another. (Does
>> Kerberos also prevent MITM?) Or you might want
On Sat, 2019-08-10 at 10:24 +0800, Craig Ringer wrote:
> Before we go too far along with this, lets look at how other
> established protocols do things and the flaws that've been discovered
> in their approaches. If this isn't done with extreme care then
> there's a large risk of negating the benef
On Fri, 9 Aug 2019 at 11:00, Michael Paquier wrote:
> On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> > Libpq doesn't have a way to control which password protocols are used.
> > For example, the client might expect the server to be using SCRAM, but
> > it actually ends up using pla
Greetings,
* Jeff Davis (pg...@j-davis.com) wrote:
> On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:
> > auth_methods = 'MITM, -password, -md5'
>
> Keep in mind this is client configuration, so something reasonable in
> postgresql.conf might not be so reasonable in the form:
Yeah, t
On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:
> This is a multi-dimensional problem. "channel_binding=require" is
> one
> way to prevent MITM attacks, but sslmode=verify-ca is another. (Does
> Kerberos also prevent MITM?) Or you might want to enable plaintext
> passwords over SSL,
On Fri, 2019-08-09 at 16:27 -0400, Jonathan S. Katz wrote:
> Seems to be a lot to configure. I'm more of a fan of the previous
> method; it'd work nicely with how we've presently defined things and
> should be easy to put into a DSN/URI/env variable.
Proposals on the table:
1. Hierarchical semant
On 09/08/2019 23:27, Jonathan S. Katz wrote:
On 8/9/19 11:51 AM, Jeff Davis wrote:
On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
Having an 'any' option, as mentioned before, could be an alternative
though.
...
I agree with the point that there isn't any guarantee that it'll
always
On 8/9/19 11:51 AM, Jeff Davis wrote:
> On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
>> Having an 'any' option, as mentioned before, could be an alternative
>> though.
>
> ...
>
>> I agree with the point that there isn't any guarantee that it'll
>> always
>> be clear-cut as to which of
On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
> Having an 'any' option, as mentioned before, could be an alternative
> though.
...
> I agree with the point that there isn't any guarantee that it'll
> always
> be clear-cut as to which of two methods is "better".
>
> From a user perspect
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Aug 08, 2019 at 11:16:24PM -0700, Jeff Davis wrote:
> > On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> > > What about auth_protocol then? It seems to me that it could be
> > > useful
> > > to have the restriction on
On Thu, Aug 08, 2019 at 11:16:24PM -0700, Jeff Davis wrote:
> On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> > What about auth_protocol then? It seems to me that it could be
> > useful
> > to have the restriction on AUTH_REQ_MD5 as well.
>
> auth_protocol does sound like a good name.
On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> What about auth_protocol then? It seems to me that it could be
> useful
> to have the restriction on AUTH_REQ_MD5 as well.
auth_protocol does sound like a good name. I'm not sure what you mean
regarding MD5 though.
> This makes it sound
On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> Libpq doesn't have a way to control which password protocols are used.
> For example, the client might expect the server to be using SCRAM, but
> it actually ends up using plain password authentication instead.
Thanks for working on thi
quot;, but other names I
could think of seemed likely to cause confusion.
Regards,
Jeff Davis
From 9d82cbad4e1bf1c3e159df6e7c8972c8fa2313ae Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Wed, 7 Aug 2019 20:17:44 -0700
Subject: [PATCH] Add "password_protocol" connection parameter t
46 matches
Mail list logo
