Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1 - Mailing list pgsql-hackers

From Steven Fackler
Subject Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Date
Msg-id CANb7cF5v4KCvC47j+9vMVKaqqwCc2tJg5WQ94993BfXJBEDnSA@mail.gmail.com
Whole thread Raw
In response to Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
List 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


On Wed, Jun 6, 2018 at 12:37 PM Peter Eisentraut <peter.eisentraut@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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Spilling hashed SetOps and aggregates to disk
Next
From: "David G. Johnston"
Date:
Subject: libpq compression