On 01/06/17 18:11, Bruce Momjian wrote:
On Wed, May 31, 2017 at 09:37:02AM -0400, Robert Haas wrote:
On Tue, May 30, 2017 at 11:49 PM, Stephen Frost <sfr...@snowman.net> wrote:
... and I don't believe that we should be asking the
implementors of channel binding to also implement support for multiple
TLS libraries in PostgreSQL in order to test that their RFC-following
(at least, as far as they can tell) implementation actually works.
You're of course free to believe what you wish, but that sounds
short-sighted to me.  If we implement channel binding and it turns out
not to be interoperable with other SSL implementations, then what?  We
can't change it later without breaking compatibility with our own
prior implementation.  Note that Álvaro Hernández Tortosa said about
two hours before you sent this email that it doesn't seem possible to
implement something comparable in Java's standard SSL stack.  If
that's the case, adopting this implementation is dooming everyone who
connects to the database server using JDBC to be unable to use channel
binding.  And that's a large percentage of our user base.
Just to step back, exactly how does channel binding work?  Is each side
of the SSL connection hashing the password hash with the shared SSL
session secret in some way that each side knows the other end knows
the password hash, but not disclosing the secret or password hash?  Is
there some other way JDBC can get that information?

In short, channel binding augments SCRAM (could be also other authentication methods, I guess) by adding to the mix of data to be exchanged, data that comes off-band. Normal SCRAM exchange involves user, a unique token, a salt and some other information. If you add into the mix off-band information, that is uniquely known by only client and server, you can avoid MITM attacks. It's not as simple as "hashing" the password, though. SCRAM involves 4 steps (2 messages each way) with somehow complex hashing of data in the last 2 steps.

There are basically 2 channel binding options, that is, 2 possible data pieces that could be taken off-band of the SCRAM authentication and throw them into this mix:

- tls-unique. It's like a unique identifier for each client-server SSL connection. It should be get from the SSL channel and there doesn't seem to be a super consistent way of getting it from the channel (in OpenSSL is an undocumented API, it's not available in normal Java stack, etc). - tls-server-end-point. Channel binding data is just a hash of a SSL certificate, as is. As such, seems to be easier to be supported across multiple OSs/SSL stacks.

However, SCRAM RFC states that if channel binding is implemented, at least tls-unique must be implemented, with others being optional (there is as of today a third one, but only applies to telnet). So in my opinion, I'd implement both of the above, for maximum flexibility, and add a field to the required scram authentication febe message with a list (aka CSV) of the channel binding mechanisms supported by this server. In this way, I believe covers support for several channel binding mechanisms and could be extended in the future should other mechanisms appear.



Álvaro Hernández Tortosa


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

Reply via email to