Re: SCRAM with channel binding downgrade attack - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: SCRAM with channel binding downgrade attack
Date
Msg-id 20181005170141.GA10421@momjian.us
Whole thread Raw
In response to Re: SCRAM with channel binding downgrade attack  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: SCRAM with channel binding downgrade attack  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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:

    https://tools.ietf.org/html/draft-badra-tls-key-exchange-00

Of course, that is just a guess.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance improvements for src/port/snprintf.c
Next
From: Tom Lane
Date:
Subject: Re: Performance improvements for src/port/snprintf.c