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

From Jacob Champion
Subject Re: Support tls-exporter as channel binding for TLSv1.3
Date
Msg-id CAAWbhmgmAuOHQO1yuT-RwuKBn2Fy11B=Z4Vw8AC9q3b4prQdMg@mail.gmail.com
Whole thread Raw
In response to Re: Support tls-exporter as channel binding for TLSv1.3  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Support tls-exporter as channel binding for TLSv1.3
List pgsql-hackers
On Mon, Sep 19, 2022 at 5:54 PM Michael Paquier <michael@paquier.xyz> wrote:
> 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.

Should we advertise support even if the client is too old to provide
an extended master secret?

> 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 :)

Well, I'm working on a next version, but it's ballooning in complexity
as I try to navigate the fix for OpenSSL 1.0.1 (which is currently
failing the tests, unsurprisingly). You mentioned not wanting to add
maintenance burden for 1.0.1, and I'm curious to see whether the
approach you have in mind would be easier than what mine is turning
out to be. Maybe we can compare notes?

--Jacob



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: oat_post_create expected behavior
Next
From: Nathan Bossart
Date:
Subject: Re: predefined role(s) for VACUUM and ANALYZE