On 12/04/17 18:09, Tom Lane wrote:
Heikki Linnakangas <hlinn...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
