From: | Steven Fackler <sfackler(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1 |
Date: | 2018-06-06 20:16:11 |
Message-ID: | CANb7cF5v4KCvC47j+9vMVKaqqwCc2tJg5WQ94993BfXJBEDnSA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(dot)eisentraut(at)2ndquadrant(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2018-06-06 20:16:36 | libpq compression |
Previous Message | Tomas Vondra | 2018-06-06 20:11:36 | Re: Spilling hashed SetOps and aggregates to disk |