On Wed, Jul 11, 2018 at 12:27:33PM +0300, Heikki Linnakangas wrote:
> Currently, there is no negotiation of the channel binding type between
> client and server. The server advertises that it supports channel binding,
> or not, and the client decides what channel binding to use. If the server
> doesn't support the binding type that the client chose, authentication will
> fail.
>
> Based on recent discussions, it looks like there's going to be differences
> in this area [1]. OpenSSL can support both tls-unique and
> tls-server-end-point. Java only supports tls-server-end-point, while GnuTLS
> only supports tls-unique. And Mac OS Secure Transports supports neither one.
> Furthermore, it's not clear how TLS v1.3 affects this. tls-unique might no
> longer be available in TLS v1.3, but we might get new channel binding types
> to replace it. So this is about to get really messy, if there is no way to
> negotiate. (Yes, it's going to be messy even with negotiation.)
>
> I think we must fix that before we release v11, because this affects the
> protocol. There needs to be a way for the server to advertise what channel
> binding types it supports.
Yes, this does make sense. From a security perspective, it doesn't
matter which channel binding method we use, assuming there are no
unfixed exploits. The difference between the channel binding methods is
explained in our PG 11 docs:
https://www.postgresql.org/docs/11/static/sasl-authentication.html#SASL-SCRAM-SHA-256
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
