Re: Some thoughts about SCRAM implementation

From: Greg Stark <stark(at)mit(dot)edu>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Some thoughts about SCRAM implementation
Date: 2017-04-15 17:06:33
Message-ID: CAM-w4HOuRhcOcHW16Fk49Vy7u3E2afjpLZWR7MPWEYcJ-CqqFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14 April 2017 at 20:20, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> Yeah, I think if you're concerned about MITM then you would also be
> concerned about MITM siphoning off your data. So you should be using
> TLS and then you don't need channel binding.

No. You can use TLS for authentication (by verifying SSL certs in both
directions) in which case TLS will protect against MITM for you. But
if you only use TLS for encryption but still want to use passwords for
authentication then there's no protection against MITM as you don't
know that the party doing the encryption is the same as the one you
authenticated to.

Channel binding is all about tying the authentication mechanism to the
encryption to guarantee that the party doing the encryption is the
same as the party you authenticated to. Otherwise someone could MITM
the TLS connection and relay the raw bytes of of the scram
negotiation. Under our md5 auth that gives them your password, under
scram they won't get the password which is a huge improvement but they
would still have the raw unencrypted data from your traffic.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-04-15 17:09:50 Re: Minor typo in partition.c
Previous Message Robert Haas 2017-04-15 16:56:32 Re: Should pg_current_wal_location() become pg_current_wal_lsn()