Re: SCRAM with channel binding downgrade attack

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
Date: 2018-10-05 17:01:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-www

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

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.

Bruce Momjian <bruce(at)momjian(dot)us>

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to


Browse pgsql-hackers by date

  From Date Subject
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

Browse pgsql-www by date

  From Date Subject
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