|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(at)paquier(dot)xyz>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>|
|Subject:||Re: SCRAM with channel binding downgrade attack|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 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 and the real
> server have the same certificate. But with tls-unique they would have
> different channel binding data, so the channel binding would detect this.
> Is that not correct?
Not correct. First, they need to steal the server certificate and
_private_ key that goes with the certificate to impersonate the owner of
the certificate. If that happens, with tls-server-end-point, a MITM
could replay what the real server sends to the MITM. You are right that
tls-unique makes it harder for a MITM to reproduce the TLS shared key
which is mixed with the password hash to prove the server knows the
I think the standard is now focusing on tls-server-end-point because
most APIs make the certificate more accessible than the TLS shared key.
There also might be exploits with TLS shared keys being cached to
improve SSL performance, particularly for https access:
Of course, that is just a guess.
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
|Next Message||David Steele||2018-10-05 17:03:44||Re: pgsql: Make WAL segment size configurable at initdb time.|
|Previous Message||Andres Freund||2018-10-05 16:58:19||Re: Performance improvements for src/port/snprintf.c|
|Next Message||Jonathan S. Katz||2018-10-05 19:28:41||Re: Postgres 11 release notes|
|Previous Message||Peter Eisentraut||2018-10-05 14:53:34||Re: SCRAM with channel binding downgrade attack|