On 31/05/17 03:39, Michael Paquier wrote:
On Tue, May 30, 2017 at 5:59 PM, Robert Haas <robertmh...@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
We're calling SSL_do_something_undocumented() and hoping that
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:
So qualifying that as a speculative method sounds a quite hard word to me.
Actually this Python patch seems to ultimately rely on the same
OpenSSL functions as your implementation.
I don't have anything against implementing tls-unique, specially as
per the RFC it is mandatory (if channel binding support is provided).
However, given the use of undocumented API, given that at least the Java
driver would have a very difficult time implementing it (basically
replacing Java's standard SSL stack with a completely external one,
BouncyCastle, which adds load, size and complexity), I would rather
focus the efforts on tls-server-end-point which only needs to access the
certificate data, something that most APIs/frameworks/languages seem to
cover much more naturally than tls-unique.
Both are equally safe and effective and so having support for both
seems sensible to me.
Álvaro Hernández Tortosa
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: