On Wed, May 31, 2017 at 09:37:02AM -0400, Robert Haas wrote:
> On Tue, May 30, 2017 at 11:49 PM, Stephen Frost <sfrost@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?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
