On Sat, May 27, 2017 at 5:59 PM, Álvaro Hernández Tortosa <a...@8kdata.com> wrote: > - tls-unique, as you mentioned, uses two undocumented APIs. This raises a > small flag about the stability and future of those APIs.
It seems to me that the question is not just whether those APIs will be available in future versions of OpenSSL, but whether they will be available in every current and future version of every SSL implementation that we may wish to use in core or that any client may wish to use. We've talked before about being able to use the Windows native SSL implementation rather than OpenSSL and it seems that there would be significant advantages in having that capability. Meanwhile, a client that reimplements the PostgreSQL wire protocol is free to use any SSL implementation it likes. If channel binding can't work unless both sides are speaking OpenSSL, then I'd say we've blown it. Also, Heikki pointed out in his PGCon talk that there's currently no way for libpq to insist on the use of SCRAM rather than plain password authentication or md5. So, if someone trojans the server, they only need to hack it to ask the client for plaintext authentication rather than SCRAM and the client will cheerfully hand over the password with no questions asked. Presumably, we need to add a connection option to insist (a) on SCRAM or (b) SCRAM + channel binding, or else this isn't going to actually provide us with any increased security. Even without that, channel binding will still let the server verify that it's really connected to the client, but that's not really doing much for us in terms of security because the client (who has the password) can always let someone else impersonate it perfectly by just handing over the password. Channel binding can't prevent that. It *could* prevent someone from impersonating the *server* but not if the server can disable the check whenever it likes by ceasing to advertise channel binding as an available option -- with no notification to the client that anything has changed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
