On Tue, May 30, 2017 at 6:50 PM, Álvaro Hernández Tortosa
<aht@8kdata.com> wrote:
> Actually this Python patch seems to ultimately rely on the same OpenSSL
> functions as your implementation.
Yup. My point is that even if those APIs are undocumented, I think
that they are not going to disappear either.
> 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.
Point taken. Well, this brings us to the point where we should have
both tls-unique and end-point to allow JDBC to work with it. Now,
thinking about it, do we really need to advertise the available
channel binding types when the client chooses the -PLUS mechanism?
Wouldn't it make sense to let the client choose what it thinks is
better and just fail the exchange with the backend if the channel type
is not supported?
> Both are equally safe and effective and so having support for both seems
> sensible to me.
I have some automatic setups that would be really simplified by just
using libpq with SSL connections if there is channel binding. And that
involves certificate deployments, I think I am not the only one to see
that present even if JDBC just supports end-point.
--
Michael