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

From Michael Paquier
Subject Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Date
Msg-id 20180606212103.GA24853@paquier.xyz
Whole thread Raw
In response to Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1  (Steven Fackler <sfackler@gmail.com>)
Responses Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
List pgsql-hackers
On Wed, Jun 06, 2018 at 01:16:11PM -0700, Steven Fackler wrote:

Thanks for the pointers, Steven.  You should avoid top-posting on this
list, this is not the style used on the Postgres lists.

> 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].

Well, it seems that we are going this API to decide if an SSL
implementation supports channel binding or not then:
https://www.postgresql.org/message-id/20180122072936.GB1772%40paquier.xyz
And for TLS 1.3 it would need to use SSL_get_version() or such with the
connection context.

> 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].

Does this mean that tls-server-end-point goes into unsupported mode?
The emails you mention (thanks!), talk about only tls-unique while the
RFCs mention all channel binding types.

> This is also the case for TLS 1.2 handshakes with session resumption [4].

Please let me think about this one, I am not completely sure yet what
that would mean for libpq and the backend code.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Needless additional partition check in INSERT?
Next
From: Claudio Freire
Date:
Subject: Re: POC: GROUP BY optimization