On Mon, Oct 8, 2018 at 12:42:39PM +0200, Peter Eisentraut wrote:
> On 05/10/2018 19:01, Bruce Momjian wrote:
> > On Fri, Oct 5, 2018 at 04:53:34PM +0200, Peter Eisentraut wrote:
> >> On 23/05/2018 08:46, Heikki Linnakangas wrote:
> >>> "tls-unique" and "tls-server-end-point" are overly technical
On 05/10/2018 19:01, Bruce Momjian wrote:
> On Fri, Oct 5, 2018 at 04:53:34PM +0200, Peter Eisentraut wrote:
>> On 23/05/2018 08:46, Heikki Linnakangas wrote:
>>> "tls-unique" and "tls-server-end-point" are overly technical to users.
>>> They don't care which one is used, there's no difference in
On Fri, Oct 5, 2018 at 04:53:34PM +0200, Peter Eisentraut wrote:
> On 23/05/2018 08:46, Heikki Linnakangas wrote:
> > "tls-unique" and "tls-server-end-point" are overly technical to users.
> > They don't care which one is used, there's no difference in security.
>
> A question was raised about
On 23/05/2018 08:46, Heikki Linnakangas wrote:
> "tls-unique" and "tls-server-end-point" are overly technical to users.
> They don't care which one is used, there's no difference in security.
A question was raised about this in a recent user group meeting.
When someone steals the server certifi
On 29.06.18 04:16, Michael Paquier wrote:
> I am able to find easily drafts of TLS 1.3, but I am not seeing an RFC
> associated to it, which would be the base document to rely on I
> guess... So that's really hard to make any decision in this area
> without the real deal. As far as I can see tls-
On Fri, Jun 29, 2018 at 10:37:55AM +0900, Michael Paquier wrote:
> The set of APIs that we use to the SSL abstraction layer is very
> internal, so it would not be an issue if we add some in stable branches,
> no? My point is that from OpenSSL point of view, TLS 1.3 stuff has been
> added in 1.1.1
On Thu, Jun 28, 2018 at 10:05:23AM +0200, Peter Eisentraut wrote:
> But before we drop the SCRAM business completely off the open items, I
> think we need to consider how TLS 1.3 affects this.
The set of APIs that we use to the SSL abstraction layer is very
internal, so it would not be an issue if
On Thu, Jun 28, 2018 at 10:04:05AM +0200, Peter Eisentraut wrote:
> On 6/28/18 09:35, Magnus Hagander wrote:
> > No, we absolutely still have SCRAM channel binding.
> >
> > *libpq* has no way to *enforce* it, meaning it always acts like our
> > default SSL config which is "use it if available but
On Thu, Jun 28, 2018 at 09:35:57AM +0200, Magnus Hagander wrote:
> No, we absolutely still have SCRAM channel binding.
>
> *libpq* has no way to *enforce* it, meaning it always acts like our default
> SSL
> config which is "use it if available but if it's not then silently accept the
> downgrade"
On Thu, Jun 28, 2018 at 10:04 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 6/28/18 09:35, Magnus Hagander wrote:
> > No, we absolutely still have SCRAM channel binding.
> >
> > *libpq* has no way to *enforce* it, meaning it always acts like our
> > default SSL config which
On 6/28/18 09:35, Magnus Hagander wrote:
> No, we absolutely still have SCRAM channel binding.
>
> *libpq* has no way to *enforce* it, meaning it always acts like our
> default SSL config which is "use it if available but if it's not then
> silently accept the downgrade". From a security perspecti
On 6/28/18 09:33, Magnus Hagander wrote:
> Should there be one or more parameters? How should they interact? At
> which level should they be controlled? Limited to SCRAM or other channel
> bindings? Are the different levels of SCRAM to be considered different
> protocols or the same protocol with a
On 6/28/18 09:35, Magnus Hagander wrote:
> No, we absolutely still have SCRAM channel binding.
>
> *libpq* has no way to *enforce* it, meaning it always acts like our
> default SSL config which is "use it if available but if it's not then
> silently accept the downgrade". From a security perspecti
On Wed, Jun 27, 2018 at 7:24 PM, Alvaro Herrera
wrote:
> Going over this thread a little bit I'm confused about what is being
> proposed. I think I understand that we no longer think we have have
> SCRAM channel binding. I hope that doesn't mean we don't have SCRAM
> itself. However, in terms
On Wed, Jun 27, 2018 at 6:55 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 6/14/18 13:43, Magnus Hagander wrote:
> > I still think that the fact that we are still discussing what is
> > basically the *basic concepts* of how this would be set up after we have
> > released bet
Going over this thread a little bit I'm confused about what is being
proposed. I think I understand that we no longer think we have have
SCRAM channel binding. I hope that doesn't mean we don't have SCRAM
itself. However, in terms of the Postgres release proper, what do we
need to do? There is
On 6/14/18 13:43, Magnus Hagander wrote:
> I still think that the fact that we are still discussing what is
> basically the *basic concepts* of how this would be set up after we have
> released beta1 is a clear sign that this should not go into 11.
Other than some naming and handling of some nonse
On Sat, Jun 23, 2018 at 10:30:19PM +0900, Michael Paquier wrote:
> On Fri, Jun 22, 2018 at 11:01:53PM -0400, Bruce Momjian wrote:
> > Uh, as I am understanding it, if we don't allow clients to force channel
> > binding, then channel binding is useless because it cannot prevent
> > man-in-the-middle
On Fri, Jun 22, 2018 at 11:01:53PM -0400, Bruce Momjian wrote:
> Uh, as I am understanding it, if we don't allow clients to force channel
> binding, then channel binding is useless because it cannot prevent
> man-in-the-middle attacks. I am sure some users will try to use it, and
> not understand
On Sun, Jun 17, 2018 at 10:21:27PM +0900, Michael Paquier wrote:
> On Fri, Jun 15, 2018 at 05:23:27PM -0400, Robert Haas wrote:
> > On Thu, Jun 14, 2018 at 7:43 AM, Magnus Hagander
> > wrote:
> >> I still think that the fact that we are still discussing what is basically
> >> the *basic concepts*
On Fri, Jun 15, 2018 at 05:23:27PM -0400, Robert Haas wrote:
> On Thu, Jun 14, 2018 at 7:43 AM, Magnus Hagander wrote:
>> I still think that the fact that we are still discussing what is basically
>> the *basic concepts* of how this would be set up after we have released
>> beta1 is a clear sign t
On Thu, Jun 14, 2018 at 7:43 AM, Magnus Hagander wrote:
> I still think that the fact that we are still discussing what is basically
> the *basic concepts* of how this would be set up after we have released
> beta1 is a clear sign that this should not go into 11.
+1.
--
Robert Haas
EnterpriseDB
On Tue, Jun 12, 2018 at 6:49 AM, Michael Paquier
wrote:
> On Mon, Jun 11, 2018 at 04:54:45PM +0200, Magnus Hagander wrote:
> > I'm wondering if that means we should then also not do it specifically
> for
> > scram in this version. Otherwise we're likely to end up with a parameter
> > that only ha
On Mon, Jun 11, 2018 at 04:54:45PM +0200, Magnus Hagander wrote:
> I'm wondering if that means we should then also not do it specifically for
> scram in this version. Otherwise we're likely to end up with a parameter
> that only has a "lifetime" of one version, and that seems like a bad idea.
> If
On Mon, Jun 11, 2018 at 4:49 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 6/6/18 18:04, Michael Paquier wrote:
> > On Wed, Jun 06, 2018 at 11:53:06PM +0300, Heikki Linnakangas wrote:
> >> That would certainly be good. We've always had that problem, even with
> md5
> >> -> p
On 6/6/18 18:04, Michael Paquier wrote:
> On Wed, Jun 06, 2018 at 11:53:06PM +0300, Heikki Linnakangas wrote:
>> That would certainly be good. We've always had that problem, even with md5
>> -> plaintext password downgrade, and it would be nice to fix it. It's quite
>> late in the release cycle alr
On Wed, Jun 06, 2018 at 11:46:11PM +0300, Heikki Linnakangas wrote:
> Ok. Perhaps add a comment pointing out that as the code stands,
> get_auth_request_str() is never called with AUTH_REQ_OK. So that if someone
> starts calling it with that, maybe they'll know to revisit this.
That makes sense.
On Wed, Jun 06, 2018 at 11:53:06PM +0300, Heikki Linnakangas wrote:
> That would certainly be good. We've always had that problem, even with md5
> -> plaintext password downgrade, and it would be nice to fix it. It's quite
> late in the release cycle already, do you think we should address that now
On 06/06/18 23:31, Peter Eisentraut wrote:
On 6/6/18 16:26, Heikki Linnakangas wrote:
On 06/06/18 23:20, Peter Eisentraut wrote:
Aren't we attacking this on the wrong level? We are here attempting to
prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not
preventing a SCRAM-SHA
On 05/06/18 09:41, Michael Paquier wrote:
On Sat, Jun 02, 2018 at 01:08:56PM -0400, Heikki Linnakangas wrote:
On 28/05/18 15:08, Michael Paquier wrote:
On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote:
+ printfPQExpBuffer(&conn->errorMessage,
+libpq_gettext("channel bindi
On 6/6/18 16:26, Heikki Linnakangas wrote:
> On 06/06/18 23:20, Peter Eisentraut wrote:
>> Aren't we attacking this on the wrong level? We are here attempting to
>> prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not
>> preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade
On 06/06/18 23:20, Peter Eisentraut wrote:
Aren't we attacking this on the wrong level? We are here attempting to
prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not
preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade.
The latest patch does prevent that, too. That wa
Aren't we attacking this on the wrong level? We are here attempting to
prevent a SCRAM-SHA-256-PLUS -> SCRAM-SHA-256 downgrade, but we are not
preventing a SCRAM-SHA-256-PLUS -> anything-else downgrade.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Sup
On Sat, Jun 02, 2018 at 01:08:56PM -0400, Heikki Linnakangas wrote:
> On 28/05/18 15:08, Michael Paquier wrote:
>> On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote:
>> > Sounds good.
>>
>> Okay. Done this way as attached. If the backend forces anything else
>> than SCRAM then t
On 28/05/18 15:08, Michael Paquier wrote:
On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote:
Sounds good.
Okay. Done this way as attached. If the backend forces anything else
than SCRAM then the client gets an immediate error if channel binding is
required, without waiting f
On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote:
> Sounds good.
Okay. Done this way as attached. If the backend forces anything else
than SCRAM then the client gets an immediate error if channel binding is
required, without waiting for the password prompt.
--
Michael
From 8d0b
On 28/05/18 12:20, Michael Paquier wrote:
On Mon, May 28, 2018 at 12:00:33PM +0300, Heikki Linnakangas wrote:
That's not a new problem, but it makes the MITM protection fairly pointless,
if a fake server can acquire the user's password by simply asking for it.
The client will report a failed con
On Mon, May 28, 2018 at 12:00:33PM +0300, Heikki Linnakangas wrote:
> That's not a new problem, but it makes the MITM protection fairly pointless,
> if a fake server can acquire the user's password by simply asking for it.
> The client will report a failed connection, but with the user's password,
On 28/05/18 04:23, Michael Paquier wrote:
On Sat, May 26, 2018 at 11:42:38PM +0900, Michael Paquier wrote:
On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote:
On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
OK, I can live with that as well. So we'll go in the dire
On Sat, May 26, 2018 at 11:42:38PM +0900, Michael Paquier wrote:
> On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote:
>> On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
>>>
>>> OK, I can live with that as well. So we'll go in the direction of two
>>> parameters then:
>
On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote:
> On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
>>
>> OK, I can live with that as well. So we'll go in the direction of two
>> parameters then:
>> - scram_channel_binding, which can use "prefer" (default), "require"
On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote:
> On Fri, May 25, 2018 at 06:24:07PM +0300, Heikki Linnakangas wrote:
> > On 25 May 2018 17:44:16 EEST, Robert Haas wrote:
> >> It seems to me that this is really another sort of thing altogether.
> >> Whether or not you want to insi
On Fri, May 25, 2018 at 06:24:07PM +0300, Heikki Linnakangas wrote:
> On 25 May 2018 17:44:16 EEST, Robert Haas wrote:
>> It seems to me that this is really another sort of thing altogether.
>> Whether or not you want to insist on channel binding is a completely
>> separate thing from which channe
On 25 May 2018 17:44:16 EEST, Robert Haas wrote:
>On Wed, May 23, 2018 at 2:46 AM, Heikki Linnakangas
>wrote:
>> We could provide "tls-unique" and "tls-server-end-point" in addition
>to
>> those, but I'd consider those to be developer only settings, useful
>only for
>> testing the protocol.
>
>
On Wed, May 23, 2018 at 2:46 AM, Heikki Linnakangas wrote:
> "tls-unique" and "tls-server-end-point" are overly technical to users. They
> don't care which one is used, there's no difference in security.
> Furthermore, if we add another channel binding type in the future, perhaps
> because someone
On Wed, May 23, 2018 at 06:41:16PM -0400, Bruce Momjian wrote:
> I can imagine someone wanting both checks so merging them into a single
> options seems unwise, as Magnus mentioned.
FWIW, definitely agreed.
--
Michael
signature.asc
Description: PGP signature
On Wed, May 23, 2018 at 11:15:28AM +0200, Magnus Hagander wrote:
> On Wed, May 23, 2018 at 11:08 AM, Heikki Linnakangas wrote:
> SCRAM, even without channel binding, does prove that you're talking to the
> correct server. Or to be precise, it proves to the client, that the server
> als
On Wed, May 23, 2018 at 11:08 AM, Heikki Linnakangas
wrote:
> On 23/05/18 09:59, Magnus Hagander wrote:
>
>> With that, a connection would be allowed, if either the server's SSL
>>> certificate is verified as with "sslmode=verify-full", *or* SCRAM
>>> authentication with channel binding was used.
On Wed, May 23, 2018 at 05:56:19PM +0900, Michael Paquier wrote:
> OK, being able to introduce a new default if necessary is a good point.
> Let's introduce a "require" mode then, which uses tls-unique
> underground, while "tls-unique" and "tls-server-end-point" are
> documented as developer-orient
On 23/05/18 09:59, Magnus Hagander wrote:
With that, a connection would be allowed, if either the server's SSL
certificate is verified as with "sslmode=verify-full", *or* SCRAM
authentication with channel binding was used. Or perhaps cram it into
sslmode, "sslmode=verify-full-or-scram-channel-bin
On Wed, May 23, 2018 at 10:56 AM, Michael Paquier
wrote:
> On Wed, May 23, 2018 at 08:59:43AM +0200, Magnus Hagander wrote:
> > On Wed, May 23, 2018 at 8:46 AM, Heikki Linnakangas
> wrote:
> >> "tls-unique" and "tls-server-end-point" are overly technical to users.
> >> They don't care which one
On Wed, May 23, 2018 at 08:59:43AM +0200, Magnus Hagander wrote:
> On Wed, May 23, 2018 at 8:46 AM, Heikki Linnakangas wrote:
>> "tls-unique" and "tls-server-end-point" are overly technical to users.
>> They don't care which one is used, there's no difference in security.
>> Furthermore, if we add
On Wed, May 23, 2018 at 8:46 AM, Heikki Linnakangas wrote:
> On 22/05/18 11:22, Michael Paquier wrote:
>
>> On Sat, May 19, 2018 at 09:35:57PM +0900, Michael Paquier wrote:
>>
>>> The previous patch has actually problems with servers using "trust",
>>> "password" and any protocol which can send d
On 22/05/18 11:22, Michael Paquier wrote:
On Sat, May 19, 2018 at 09:35:57PM +0900, Michael Paquier wrote:
The previous patch has actually problems with servers using "trust",
"password" and any protocol which can send directly AUTH_REQ_OK as those
could still enforce a downgrade to not use chan
On Tue, May 22, 2018 at 08:19:34PM -0400, Bruce Momjian wrote:
> Since tls-unique and tls-server-end-point provide the same level of
> security, I don't see any value in allowing prefer-tls-server-end-point,
> as you stated above.
Thanks. We are on the same line for this portion then.
--
Michael
On Tue, May 22, 2018 at 05:22:19PM +0900, Michael Paquier wrote:
> On Sat, May 19, 2018 at 09:35:57PM +0900, Michael Paquier wrote:
> > The previous patch has actually problems with servers using "trust",
> > "password" and any protocol which can send directly AUTH_REQ_OK as those
> > could still e
On Sat, May 19, 2018 at 09:35:57PM +0900, Michael Paquier wrote:
> On Fri, May 18, 2018 at 09:30:22AM -0400, Bruce Momjian wrote:
> > Good work, but I think the existance of both scram_channel_binding and
> > channel_binding_mode in libpq is confusing. I am thinking we should
> > have one channel
On Sat, May 19, 2018 at 09:35:57PM +0900, Michael Paquier wrote:
> The previous patch has actually problems with servers using "trust",
> "password" and any protocol which can send directly AUTH_REQ_OK as those
> could still enforce a downgrade to not use channel binding, so we
> actually need to m
On Fri, May 18, 2018 at 09:30:22AM -0400, Bruce Momjian wrote:
> Good work, but I think the existance of both scram_channel_binding and
> channel_binding_mode in libpq is confusing. I am thinking we should
> have one channel binding parameter that can take values "prefer",
> "tls-unique", "tls-ser
On Fri, May 18, 2018 at 12:03:49PM +0900, Michael Paquier wrote:
> On Fri, May 18, 2018 at 10:46:46AM +0900, Michael Paquier wrote:
> > From a security point of view, 1) is important for libpq, but I am not
> > much enthusiast about 2) as a whole. The backend has proper support for
> > channel bin
On Fri, May 18, 2018 at 10:46:46AM +0900, Michael Paquier wrote:
> From a security point of view, 1) is important for libpq, but I am not
> much enthusiast about 2) as a whole. The backend has proper support for
> channel binding, hence other drivers speaking the protocol could have
> their own re
On Fri, May 18, 2018 at 10:46:46AM +0900, Michael Paquier wrote:
> On Thu, May 17, 2018 at 10:05:25AM -0400, Bruce Momjian wrote:
> > Agreed. The problem was so glaring that I assumed I was not
> > understanding it. I have modified this email subject so users will
> > hopefully read back in this
On Thu, May 17, 2018 at 10:05:25AM -0400, Bruce Momjian wrote:
> Agreed. The problem was so glaring that I assumed I was not
> understanding it. I have modified this email subject so users will
> hopefully read back in this thread to see the details.
Okay, let's use this new thread then for the
On Thu, May 17, 2018 at 03:38:36PM +0200, Magnus Hagander wrote:
> What's the take of others? Magnus, Stephen or Heikki perhaps (you've
> been the most involved with SCRAM early talks)?
>
> Saw it by luck. It would probably be better if it wasn't hidden deep in a
> thread about release no
64 matches
Mail list logo
