On 12/04/17 18:09, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 04/12/2017 06:26 PM, Bruce Momjian wrote:
>>> How does it do that?
>> Good question, crypto magic? I don't know the details, but the basic
>> idea is that you extract a blob of data that uniquely identifies the TLS
>> connection. Using some OpenSSL functions, in this case. I think it's a
>> hash of some of the TLS handshake messages that were used when the TLS
>> connection was established (that's what "tls-unique" means). That data
>> is then incorporated in the hash calculations of the SCRAM
>> authentication. If the client and the server are not speaking over the
>> same TLS connection, they will use different values for the TLS data,
>> and the SCRAM computations will not match, and you get an authentication
>> failure.
I believe the above is not correct. Channel binding data is *not*
used for any hash computations. It is simply a byte array that is
received as an extra user parameter, and the server then gets it by its
own way (its own TLS data) and do a byte comparison. That's what the
RFCs say about it.
> ... which the user can't tell apart from having fat-fingered the password,
> I suppose? Doesn't sound terribly friendly. A report of a certificate
> mismatch is far more likely to lead people to realize there's a MITM.
So given what I said before, that won't happen. Indeed, SCRAM RFC
contains a specific error code for this: "channel-bindings-dont-match".
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data