On Tue, May 30, 2017 at 6:50 PM, Álvaro Hernández Tortosa <a...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers