Re: Support tls-exporter as channel binding for TLSv1.3

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support tls-exporter as channel binding for TLSv1.3
Date: 2022-09-20 00:53:58
Message-ID: YykPJt9BpK1kWVU7@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 19, 2022 at 09:27:41AM -0700, Jacob Champion wrote:
> While looking into this I noticed that I left the following code in place:
>
>> #ifdef HAVE_BE_TLS_GET_CERTIFICATE_HASH
>> if (strcmp(selected_mech, SCRAM_SHA_256_PLUS_NAME) == 0 && port->ssl_in_use)
>
> In other words, we're still deciding whether to advertise -PLUS based
> only on whether we support tls-server-end-point.

X509_get_signature_nid() has been introduced in 1.0.2.
SSL_export_keying_material() is older than that, being present since
1.0.1. Considering the fact that we want to always have
tls-server-end-point as default, it seems to me that we should always
publish SCRAM-SHA-256-PLUS and support channel binding when building
with OpenSSL >= 1.0.2. The same can be said about the areas where we
have HAVE_BE_TLS_GET_[PEER_]CERTIFICATE_HASH.

There could be a point in supporting tls-exporter as default in 1.0.1,
or just allow it if the caller gives it in the connection string, but
as that's the next version we are going to drop support for (sooner
than later would be better IMO), I don't really want to add more
maintenance burden in this area as 1.0.1 is not that used anyway as
far as I recall.

> Maybe all the necessary features landed in OpenSSL in the same
> version, but I haven't double-checked that, and in any case I think
> I need to make this code more correct in the next version of this
> patch.

I was planning to continue working on this patch based on your latest
review. Anyway, as that's originally your code, I am fine to let you
take the lead here. Just let me know which way you prefer, and I'll
stick to it :)
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-09-20 01:08:41 Re: pg_upgrade test failure
Previous Message James Coleman 2022-09-20 00:51:37 Re: Support pg_attribute_aligned and noreturn in MSVC