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,

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to