Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Date
Msg-id CAB7nPqShOtc15RyUrsX31StGOXwT9hDW1MPt49_OiR50p-sfSw@mail.gmail.com
Whole thread Raw
In response to Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256  (Álvaro Hernández Tortosa <aht@8kdata.com>)
Re: [HACKERS] Channel binding support for SCRAM-SHA-256  (Álvaro Hernández Tortosa <aht@8kdata.com>)
List pgsql-hackers
On Tue, May 30, 2017 at 5:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> That sounds like undue optimism to me.  Unless somebody's tested that
> Michael's proposed implementation, which uses undocumented OpenSSL
> APIs, actually interoperates properly with a SCRAM + channel binding
> implementation based on some other underlying SSL implementation, we
> can't really know that it's going to work.  It's not like we're
> calling SSL_do_the_right_thing_for_channel_binding_thing_per_rfc5929().
> We're calling SSL_do_something_undocumented() and hoping that
> something_undocumented ==
> the_right_thing_for_channel_binding_thing_per_rfc5929.  Could be true,
> but without actual interoperability testing it sounds pretty
> speculative to me.

Hm? Python is using that stuff for a certain amount of years now, for
the same goal of providing channel binding for SSL authentication. You
can look at this thread:
https://bugs.python.org/issue12551
So qualifying that as a speculative method sounds a quite hard word to me.
--
Michael


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] pg_config --version-num
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] TAP backpatching policy