Re: Support tls-exporter as channel binding for TLSv1.3 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support tls-exporter as channel binding for TLSv1.3
Date
Msg-id YykPJt9BpK1kWVU7@paquier.xyz
Whole thread Raw
In response to Re: Support tls-exporter as channel binding for TLSv1.3  (Jacob Champion <jchampion@timescale.com>)
Responses Re: Support tls-exporter as channel binding for TLSv1.3
List 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

Attachment

pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Support pg_attribute_aligned and noreturn in MSVC
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade test failure