TLS 1.3, (which is currently in a draft state, but is theoretically being finalized soon) does not support the TLS channel binding algorithms [1]. >From talking with one of the people working on the TLS 1.3 standard, tls-unique is seen as particularly problematic. There's some discussion on the IETF mailing lists from a couple of years ago [2].
Ignoring that line of the draft, the current tls-unique implementation in Postgres is currently incorrect for TLS 1.3 handshakes anyway since the server sends the first Finished message rather than the client [3]. This is also the case for TLS 1.2 handshakes with session resumption [4]. Steven [1]: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-C.5 [2]: https://www.ietf.org/mail-archive/web/tls/current/msg18257.html [3]: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-2 [4]: https://tools.ietf.org/html/rfc5246#section-7.3 On Wed, Jun 6, 2018 at 12:37 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 6/6/18 12:37, Alvaro Herrera wrote: > > If SCRAM channel binding is an important aspect to security, and the > > older OpenSSL versions will still be around in servers for some time > > yet, it seems like it behooves us to go the extra mile and provide an > > implementation that works with such existing servers. Looking at > > yum.postgresql.org, we seem to offer Postgres 11 packages for RHEL 6, > > which appears to have openssl 1.0.0. > > There are two channel binding types: tls-unique and > tls-server-end-point. Of the two, tls-unique is the "better" one. We > do support that without a problem. tls-server-end-point is for SSL > implementations that cannot support tls-unique, because the SSL library > does not expose the required information. Most prominently, this is for > JDBC. > > So currently, we support channel binding using tls-unique just fine > between libpq and a server. And we support tls-server-end-point between > JDBC and a server using new-ish OpenSSL. We don't support any channel > binding between for example JDBC and a server on CentOS 6. But that's > not a regression, it's just not there. > > As Heikki was saying, the proposed patch seems to tread into the > portability problem territory that caused the previous attempt to fail > and had to be reverted. I am not that interested in trying that again > without new insights. I don't think we are going to do ourselves a > favor if we start meddling with that again. There are dozens of OpenSSL > variants out there, and the version history is nonlinear. > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
