From: Jonathan S. Katz <jkatz@postgresql.org>
To: Jeff Davis <pgsql@j-davis.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
To: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Add "password_protocol" connection parameter to libpq
Date: Sat, 10 Aug 2019 11:08:46 -0400
Message-ID: <e370dce7-9471-2dcc-41e7-f334389ecdfd@postgresql.org> (raw)
In-Reply-To: <a977da04af60668c487a7a21abbcbb87b9ea8344.camel@j-davis.com>
References: <227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel@j-davis.com>
<20190809030021.GG3194@paquier.xyz>
<3bbf5968ea705700a2605d6db74d8510bea7940b.camel@j-davis.com>
<20190809100922.GI3194@paquier.xyz>
<20190809132850.GL16436@tamriel.snowman.net>
<609482826475e0063c7d71b2449ae31c0d61b232.camel@j-davis.com>
<071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
<dc2c84d5-92d3-acbc-4f39-2846d0c5a72d@iki.fi>
<a977da04af60668c487a7a21abbcbb87b9ea8344.camel@j-davis.com>
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 to enable plaintext
>> passwords over SSL, but not without SSL.
>>
>> I think we'll need something like the 'ssl_ciphers' GUC, where you
>> can
>> choose from a few reasonable default rules, but also enable/disable
>> specific methods:
>
> ..
>
>> 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:
>
> postgresql://foo:secret@myhost/mydb?auth_methods=MITM%2C%20-
> password%2C%20-md5
Yeah, and I do agree it is a multi-dimensional problem, but the context
in which I gave my opinion was for the password authentication methods
that PostgreSQL supports natively, i.e. not requiring a 3rd party to
arbitrate via GSSAPI, LDAP etc.
That said, I dove into the code a bit more to look at the behavior
specifically with LDAP, which as described does send back a request for
"AuthenticationCleartextPassword"
If we go with the client sending up a "password_protocol" that is not
plaintext, and the server only provides LDAP authentication, does the
client close the connection? I would say yes.
(And as such, I would also consider adding "plaintext" back to the list,
just to have the explicit option).
The other question I have is that do we have it occur in the
hierarchical manner, i.e. "md5 or better?" I would also say yes to that,
we would just need to clearly document that. Perhaps we adopt a similar
name to "sslmode" e.g. "password_protocol_mode" but that can be debated :)
> Another thing to consider is that there's less control configuring on
> the client than on the server. The server will send at most one
> authentication request based on its own rules, and all the client can
> do is either answer it, or disconnect. And the SSL stuff all happens
> before that, and won't use an authentication request message at all.
Yes. Using the LDAP example above, the client also needs some general
awareness of how it can connect to the server, e.g. "You may want
scram-sha-256 but authentication occurs over LDAP, so don't stop
requesting scram-sha-256!" That said, part of that is a human problem:
it's up to the server administrator to inform clients how they can
connect to PostgreSQL.
> Some protocols allow negotiation within them, like SASL, which gives
> the client a bit more freedom. But FE/BE doesn't allow for arbitrary
> subsets of authentication methods to be negoitated between client and
> server, so I'm worried trying to express it that way will just lead to
> clients that break when you upgrade your server.
Agreed. I see this as a way of a client saying "Hey, I really want to
authenticate with scram-sha-256 or better, so if you don't let me do
that, I'm out." In addition to ensuring it uses the client's desired
password protocol, this could be helpful for testing that the
appropriate authentication rules are set in a server, e.g. one that is
rolling out SCRAM authentication.
And as Heikki mentions, there are other protections a client can use,
e.g. verify-ca/full, to guard against eavesdropping, MITM etc.
Jonathan
Attachments:
[application/pgp-signature] signature.asc (832B, ../e370dce7-9471-2dcc-41e7-f334389ecdfd@postgresql.org/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jkatz@postgresql.org, pgsql@j-davis.com, hlinnaka@iki.fi, sfrost@snowman.net, michael@paquier.xyz
Subject: Re: Add "password_protocol" connection parameter to libpq
In-Reply-To: <e370dce7-9471-2dcc-41e7-f334389ecdfd@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox