Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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 >

Re: SCRAM with channel binding downgrade attack

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

SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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 > >

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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 > >> ->

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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.

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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(>errorMessage, +libpq_gettext("channel binding

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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,

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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:

Re: SCRAM with channel binding downgrade attack

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"

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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,

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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,

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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. >>

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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",

Re: SCRAM with channel binding downgrade attack

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

Re: SCRAM with channel binding downgrade attack

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

SCRAM with channel binding downgrade attack

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