I know you know that, but for the benefit of bystanders reading
the threads, I think we should stop phrasing it like this. Most people
who want MITM protection need to be using verify-full.
Details for those bystanders: Channel binding alone will only
disconnect you after the MITM is discovered, after
> able to negotiate which channel binding to use (I recall that the
> surrounding RFCs allowed some extra negotiation, vaguely, but my
> impression may be wrong).
I am not sure what can be done for that now, so I have marked the
patch as returned with feedback.
--
Michael
signature.asc
Description: PGP signature
w more about all that, and it looks like we would need a way to be
able to negotiate which channel binding to use (I recall that the
surrounding RFCs allowed some extra negotiation, vaguely, but my
impression may be wrong).
--
Michael
signature.asc
Description: PGP signature
On Wed, Oct 12, 2022 at 11:01 PM Michael Paquier wrote:
> One thing that would reduce the complexity of the equation is
> to drop support for tls-server-end-point in the backend in PG >= 16 as
> the versions of OpenSSL we still support on HEAD would cover
> completely tls-exporter.
Is the intent
-server-end-point. What we would (usually) like to happen, is to fall
>> back to not using channel binding. But it's not clear how to make that
>> work, and still protect from downgrade attacks.
>
> The problem was deferred when tls-unique was removed. We might have to
> a
ing the case that Heikki pointed
out several years ago [1]:
> The problematic case is when e.g. the server
> only supports tls-unique and the client only supports
> tls-server-end-point. What we would (usually) like to happen, is to fall
> back to not using channel binding. But it'
s to me that we should always
> publish SCRAM-SHA-256-PLUS and support channel binding when building
> with OpenSSL >= 1.0.2. The same can be said about the areas where we
> have HAVE_BE_TLS_GET_[PEER_]CERTIFICATE_HASH.
Should we advertise support even if the client is too old to pr
e fact that we want to always have
tls-server-end-point as default, it seems to me that we should always
publish SCRAM-SHA-256-PLUS and support channel binding when building
with OpenSSL >= 1.0.2. The same can be said about the areas where we
have HAVE_BE_TLS_GET_[PEER_]CERTIFICATE_HASH.
On Wed, Sep 7, 2022 at 10:03 AM Jacob Champion wrote:
> Yeah, that should be fine. Requiring newer OpenSSLs for stronger
> crypto will probably be uncontroversial.
While looking into this I noticed that I left the following code in place:
> #ifdef HAVE_BE_TLS_GET_CERTIFICATE_HASH
> if (strcm
On Wed, Aug 31, 2022 at 5:57 PM Michael Paquier wrote:
> On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote:
> > OpenSSL should have an API for that (SSL_get_extms_support); I don't
> > know when it was introduced.
>
> This is only available from 1.1.0, meaning that we'd better disable
On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote:
> For protocols less than 1.3 we'll need to ensure that the extended
> master secret is in use:
>
>This channel binding mechanism is defined only when the TLS handshake
>results in unique master secrets.
On Sun, Aug 28, 2022 at 11:02 PM Michael Paquier wrote:
> RFC9266, that has been released not so long ago, has added
> tls-exporter as a new channel binding type:
> https://www.rfc-editor.org/rfc/rfc5929.html
Hi Michael, thank you for sending this!
> Note also that tls-exporter
Hi all,
RFC9266, that has been released not so long ago, has added
tls-exporter as a new channel binding type:
https://www.rfc-editor.org/rfc/rfc5929.html
An advantage over tls-server-end-point, AFAIK, is that this prevents
man-in-the-middle attacks even if the attacker holds the server&#
On Fri, Feb 15, 2019 at 10:21:12PM -0500, Bruce Momjian wrote:
> Well, my point was that this features was considered to be very
> important for PG 11, but for some reason there has been no advancement
> of this features for PG 12.
Yeah, it is unfortunate that we have not seen patches about that o
On Sat, Feb 16, 2019 at 10:12:19AM +0900, Michael Paquier wrote:
> On Fri, Feb 15, 2019 at 04:17:07PM -0500, Bruce Momjian wrote:
> > We removed channel binding from PG 11 in August of 2018 because we were
> > concerned about downgrade attacks. Are there any plans to enable i
On Fri, Feb 15, 2019 at 04:17:07PM -0500, Bruce Momjian wrote:
> We removed channel binding from PG 11 in August of 2018 because we were
> concerned about downgrade attacks. Are there any plans to enable it for
> PG 12?
The original implementation of channel binding for SCRAM has
We removed channel binding from PG 11 in August of 2018 because we were
concerned about downgrade attacks. Are there any plans to enable it for
PG 12?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I
als the server certificate from the real database server
> >> and sets up a MITM with that certificate, this would pass
> >> tls-server-end-point channel binding, because both the MITM and the real
> >> server have the same certificate. But with tls-unique they would
#x27;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 certificate from the real database server
>> and sets up a MITM with that certificate, this
n security.
>
> A question was raised about this in a recent user group meeting.
>
> When someone steals the server certificate from the real database server
> and sets up a MITM with that certificate, this would pass
> tls-server-end-point channel binding, because both the MITM
ing.
When someone steals the server certificate from the real database server
and sets up a MITM with that certificate, this would pass
tls-server-end-point channel binding, because both the MITM and the real
server have the same certificate. But with tls-unique they would have
different channel bindin
On Fri, Aug 31, 2018 at 12:18:52PM +0200, Peter Eisentraut wrote:
> I was updating the gnutls patch for the changed channel binding setup,
> and I noticed that the 002_scram.pl test now passes even though the
> gnutls patch currently does not support channel binding. So AFAICT,
&g
onnections
> when the client enforced cbind_flag to 'n' as that would be useful when
> adding new SSL implementations as that would avoid manual tests which
> people will most likely forget, but well...
I was updating the gnutls patch for the changed channel binding setup,
and
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 07/08/18 17:34, Stephen Frost wrote:
> >Now- if we thought that maybe there was some connection pooling solution
> >that could be made to work with SSL+SCRAM if channel binding is turned
> >off, then that'
On 07/08/18 17:34, Stephen Frost wrote:
* Michael Paquier (mich...@paquier.xyz) wrote:
On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
Well, it'd be useless for users, there is no reason to switch off channel
bindi
On Tue, Aug 7, 2018 at 11:08:12PM +0300, Heikki Linnakangas wrote:
> >I know this is an academic question now, but I am not sure this is true.
> >A man-in-the-middle attacker could say they don't support channel
> >binding to the real client and real server and pretend t
channel binding is not used, the client sends a flag to the server to
indicate if it's because the client doesn't support channel binding, or
because it thought that the server doesn't support it. This is the
gs2-cbind-flag. How should the flag be set, if the server supports channel
On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
> On 12/07/18 07:14, Michael Paquier wrote:
> >On Wed, Jul 11, 2018 at 03:01:03PM +0300, Heikki Linnakangas wrote:
> >>I started digging into this more closely, and ran into a little problem. If
> >>
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
> > On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
> >> Well, it'd be useless for users, there is no reason to switch off channel
> >
On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
> On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
>> Well, it'd be useless for users, there is no reason to switch off channel
>> binding if both the client and server support it. It might not add any
On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
> Well, it'd be useless for users, there is no reason to switch off channel
> binding if both the client and server support it. It might not add any
> security you care about, but it won't do any harm either. The
&g
On 28/05/18 06:46, Michael Paquier wrote:
On Thu, Mar 08, 2018 at 02:19:55PM -0500, Peter Eisentraut wrote:
Moved to next CF along with those other two patches.
Attached is a refreshed patch for this thread, which failed to apply
after recent changes. This is tied with patches for other SSL
i
On 5 August 2018 19:01:04 EEST, Tom Lane wrote:
>Heikki Linnakangas writes:
>> Sorry, I see now that there was indeed a test for
>> scram_channel_binding='', which meant "no channel binding". That was
>> confusing, I assumed '' was the default
Heikki Linnakangas writes:
> Sorry, I see now that there was indeed a test for
> scram_channel_binding='', which meant "no channel binding". That was
> confusing, I assumed '' was the default.
Ugh, it isn't? There's a general principle in lib
deed a test for
scram_channel_binding='', which meant "no channel binding". That was
confusing, I assumed '' was the default.
I'm hoping that we add a libpq option to actually force channel binding
soon. That'll make channel binding actually useful to users,
eah,
it would be nice to have some, but this commit didn't really change that
situation.
I'm hoping that we add a libpq option to actually force channel binding
soon. That'll make channel binding actually useful to users, but it will
also make it easier to write tests to check that
On Sun, Aug 05, 2018 at 03:30:43PM +0300, Heikki Linnakangas wrote:
> That test just tested that the scram_channel_binding libpq option works, but
> I removed the option. I know you wanted to keep it as a feature flag, but as
> discussed earlier, I don't think that'd be useful.
Sorry for the noise
work. And I fixed the other
comment typos etc. that you pointed out.
Two things that I am really unhappy about is first that you completely
wiped out the test suite for channel binding. We know that channel
binding will be used once HAVE_X509_GET_SIGNATURE_NID is set, hence why
didn't you kee
> comment typos etc. that you pointed out.
Two things that I am really unhappy about is first that you completely
wiped out the test suite for channel binding. We know that channel
binding will be used once HAVE_X509_GET_SIGNATURE_NID is set, hence why
didn't you keep the check on supports_tls
Thanks for the review!
On 22/07/18 16:54, Michael Paquier wrote:
On Fri, Jul 20, 2018 at 08:05:04PM +0300, Heikki Linnakangas wrote:
This removes the scram_channel_binding libpq option altogether, since there
is now only one supported channel binding type.
This can also be used to switch off
hannel_binding libpq option altogether, since there
> is now only one supported channel binding type.
This can also be used to switch off channel binding on the client-side,
which is the behavior you could get only by using a version of libpq
compiled with v10 in the context of an SSL connection.
On 12/07/18 16:08, Michael Paquier wrote:
On Thu, Jul 12, 2018 at 12:34:51PM +0300, Heikki Linnakangas wrote:
Hmm. That is actually in a section called "Default Channel Binding". And the
first paragraph says "A default channel binding type agreement process for
all SASL applic
On Wed, Jul 11, 2018 at 04:00:47PM +0300, Heikki Linnakangas wrote:
> Looking at the GnuTLS docs, I believe it has everything we need.
> gnutls_certificate_get_peers() and gnutls_certificate_get_ours() can be used
> to get the certificate, and gnutls_x509_crt_get_signature_algorithm() gets
> the si
tml_node/Channel-Bindings.html
> Hmm. That is actually in a section called "Default Channel Binding". And the
> first paragraph says "A default channel binding type agreement process for
> all SASL application protocols that do not provide their own channel binding
> type agreemen
plemented and is the default.
[ ... digging ... ]
Here you go:
https://tools.ietf.org/html/rfc5802#section-6.1
Meh. We're not going implement tls-unique, anyway, in some of the
upcoming non-OpenSSL TLS implementations that don't support it.
Hmm. That is actually in a section called
On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
> It seems that all implementations can support tls-server-end-point, after
> all, so I'm not too worried about this anymore. The spec says that it's the
> default, but I don't actually see any advantage to using it over
> tls-serv
On 12/07/18 07:14, Michael Paquier wrote:
On Wed, Jul 11, 2018 at 03:01:03PM +0300, Heikki Linnakangas wrote:
I started digging into this more closely, and ran into a little problem. If
channel binding is not used, the client sends a flag to the server to
indicate if it's because the c
case for that.
Okay, fine for me.
> I started digging into this more closely, and ran into a little problem. If
> channel binding is not used, the client sends a flag to the server to
> indicate if it's because the client doesn't support channel binding, or
> because it though
On Wed, Jul 11, 2018 at 04:00:47PM +0300, Heikki Linnakangas wrote:
> In a nutshell, to get the token for tls-server-end-point, you need to get
> the peer's certificate from the TLS library, in raw DER format, and
> calculate a hash over it. The hash algorithm depends on the
> signatureAlgorithm in
ac OS Secure Transports supports
neither one. Furthermore, it's not clear how TLS v1.3 affects this.
tls-unique might no longer be available in TLS v1.3, but we might get
new channel binding types to replace it. So this is about to get really
messy, if there is no way to negotiate. (Yes, it's go
other options associated to a
given SASL mechanism? It seems to me that something like the following
is better long-term, with channel binding available as a comma-separated
list of items:
SCRAM-SHA-256-PLUS channel_bindings=tls-unique,tls-server-end-point
SCRAM-SHA-256
That would be more complicat
ated to a
given SASL mechanism? It seems to me that something like the following
is better long-term, with channel binding available as a comma-separated
list of items:
SCRAM-SHA-256-PLUS channel_bindings=tls-unique,tls-server-end-point
SCRAM-SHA-256
> Thoughts? Unfortunately this breaks com
On Wed, Jul 11, 2018 at 12:27:33PM +0300, Heikki Linnakangas wrote:
> Currently, there is no negotiation of the channel binding type between
> client and server. The server advertises that it supports channel binding,
> or not, and the client decides what channel binding to use. If t
Currently, there is no negotiation of the channel binding type between
client and server. The server advertises that it supports channel
binding, or not, and the client decides what channel binding to use. If
the server doesn't support the binding type that the client chose,
authentic
as I can see tls-unique could be
> deprecated and replaced, but from OpenSSL point of view it technically
> works.
At this point, I think we can leave it as is until they came out with a
new channel binding type.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL De
Actually, I got curious about that part and just compiled Postgres with
OpenSSL 1.1.1 beta 6 that I compiled manually, and channel binding is
generating consistent data for both tls-unique and tls-server-end-point
even if TLS v1.3 is used, while tests in src/test/ssl/ are all able to
pass. So t
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
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 silent
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
&
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 do
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 do
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
>
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 t
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 6/23/18 17:09, Bruce Momjian wrote:
> On Wed, Jun 6, 2018 at 01:16:11PM -0700, Steven Fackler wrote:
>> TLS 1.3, (which is currently in a draft state, but is theoretically being
>> finalized soon) does not support the TLS channel binding algorithms [1]. From
>
> Uh, acco
On Tue, Jun 19, 2018 at 09:19:40AM +0900, Michael Paquier wrote:
> As Peter and Heikki have worked as well on all those features with me,
> are there any objection to discard this open item? I looked again at
> the patch this morning and it is true that OpenSSL's history makes
> things harder, so
at servers JDBC
would be able to connect to (using SCRAM + channel binding). Only those
with tls-server-end-point will be able to use CB with JDBC, and that is,
as of today, only OpenSSL 1.0.2 or higher, which is not available on
some older distributions.
Álvaro
--
Alvaro Hernandez
---
OnGres
On 29 May 2018 at 22:48, Michael Paquier wrote:
> On Tue, May 29, 2018 at 10:33:03PM -0400, Heikki Linnakangas wrote:
> > Hmm. I think Peter went through this in commits ac3ff8b1d8 and
> 054e8c6cdb.
> > If you got that working now, I suppose we could do that, but I'm actually
> > inclined to just
On Wed, Jun 6, 2018 at 01:16:11PM -0700, Steven Fackler wrote:
> TLS 1.3, (which is currently in a draft state, but is theoretically being
> finalized soon) does not support the TLS channel binding algorithms [1]. From
Uh, according to this article, TLS 1.3 was finalized in March:
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 pr
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
&g
> >> 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.
>
> Yes, that sounds right.
Uh, as I am understanding it, if we don't allow clients to force channel
bindi
On Sat, Jun 09, 2018 at 09:28:17AM +0900, Michael Paquier wrote:
> I am still not completely sure what is the correct course of action
> here. Heikki and Peter and not much in favor of adding more complexity
> here as OpenSSL has a long history of having a non-linear history across
> platforms. O
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
end to think that we should have in this future
> "allowed_authentication_methods" only scram-sha-256 listed as an option,
> which counts for both SCRAM with and without channel binding.
>
One could argue they are equally the same protocol if we have
SCRAM-SHA-512 or whatever in the
same
protocol so it would be confusing for the user to be able to define both
SCRAM-SHA-256 and SCRAM-SHA-256-PLUS within the same list, so I would
tend to think that we should have in this future
"allowed_authentication_methods" only scram-sha-256 listed as an option,
which counts for both
On Mon, Jun 11, 2018 at 10:47:23AM -0400, Peter Eisentraut wrote:
> I think we'll just have to wait for an updated RFC on channel bindings
> for TLS 1.3.
>
> Perhaps we should change PostgreSQL 11 to not advertise channel binding
> when TLS 1.3 is used?
Yeah, that's what
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 6/6/18 16:16, Steven Fackler wrote:
> TLS 1.3, (which is currently in a draft state, but is theoretically
> being finalized soon) does not support the TLS channel binding
> algorithms [1]. From talking with one of the people working on the TLS
> 1.3 standard, tls-unique is seen as
On Wed, Jun 06, 2018 at 12:37:00PM -0400, Alvaro Herrera wrote:
> On 2018-May-29, Michael Paquier wrote:
> If SCRAM channel binding is an important aspect to security, and the
> older OpenSSL versions will still be around in servers for some time
> yet, it seems like it behooves us to
at makes sense. Done.
>> +
>> + prefer (default)
>> +
>> +
>> +Use channel binding if available. If the cluster does not
>> +support it, then it is not used. This is the default.
>> +
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
goes into unsupported mode?
> The emails you mention (thanks!), talk about only tls-unique while the
> RFCs mention all channel binding types.
>
That's the part that I'm unsure about - tls-server-end-point doesn't seem
particularly objectionable. I asked for some clarification f
es not support the TLS channel binding algorithms [1].
> From talking with one of the people working on the TLS 1.3 standard,
> tls-unique is seen as particularly problematic. There's some discussion on
> the IETF mailing lists from a couple of years ago [2].
Well, it seems that we a
)
OK, that would do, but we don't do anything about a SCRAM-SHA-256 ->
anything-else downgrade. Instead of tying this to the channel binding,
should we tie it to the authentication type?
That would certainly be good. We've always had that problem, even with
md5 -> plaintext p
quot;channel binding required for authentication but invalid protocol
used\n"));
If I understand correctly, you get this error, e.g. if you have "password"
or "sspi" in pg_hba.conf, and the client uses
"channel_binding_mode=require". "Invalid protocol&quo
that's a bug.)
OK, that would do, but we don't do anything about a SCRAM-SHA-256 ->
anything-else downgrade. Instead of tying this to the channel binding,
should we tie it to the authentication type?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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
TLS 1.3, (which is currently in a draft state, but is theoretically being
finalized soon) does not support the TLS channel binding algorithms [1].
>From talking with one of the people working on the TLS 1.3 standard,
tls-unique is seen as particularly problematic. There's some discussio
On 6/6/18 12:37, Alvaro Herrera wrote:
> If SCRAM channel binding is an important aspect to security, and the
> older OpenSSL versions will still be around in servers for some time
> yet, it seems like it behooves us to go the extra mile and provide an
> implementation that wor
Alvaro Herrera writes:
> If SCRAM channel binding is an important aspect to security, and the
> older OpenSSL versions will still be around in servers for some time
> yet, it seems like it behooves us to go the extra mile and provide an
> implementation that works with such exis
that HEAD is cleaner with its simplicity.
>
> Steven, as the initial reporter, what's your take?
If SCRAM channel binding is an important aspect to security, and the
older OpenSSL versions will still be around in servers for some time
yet, it seems like it behooves us to go the extra mile
ything else
>> than SCRAM then the client gets an immediate error if channel binding is
>> required, without waiting for the password prompt.
>
> Thanks! The comments and error messages need some copy-editing:
Thanks Heikki for the input. I have re
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
1 - 100 of 189 matches
Mail list logo
