On 04/12/2017 06:26 PM, Bruce Momjian wrote:
> On Wed, Apr 12, 2017 at 12:13:03PM +0300, Heikki Linnakangas wrote:
>>> That said, I stand by my comment that I don't think it's the enterprises
>>> that need or want the channel binding. If they care about it, they have
>>> already put certificate validation in place, and it won't buy them anything.
>>>
>>> Because channel binding also only secures the authentication (SCRAM), not
>>> the actual contents and commands that are then sent across the channel,
>>> AFAIK?
>>
>> TLS protects the contents and the commands. The point of channel binding is
>> to defeat a MITM attack, where the client connects to a malicious server,
>> using TLS, which then connects to the real server, using another TLS
>> connection. Channel binding will detect that the client and the real server
>> are not communicating over the same TLS connection, but two different TLS
>> connections, and make the authentication fail.
>>
>> SSL certificates, with validation, achieves the same, but channel binding
>> achieves it without the hassle of certificates.
>
> 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.
- Heikki
