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

From: Jacob Champion <jchampion(at)timescale(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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 18:01:29
Message-ID: CAAWbhmgmAuOHQO1yuT-RwuKBn2Fy11B=Z4Vw8AC9q3b4prQdMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 19, 2022 at 5:54 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-09-20 18:05:33 Re: predefined role(s) for VACUUM and ANALYZE
Previous Message Jeff Davis 2022-09-20 17:58:17 Re: oat_post_create expected behavior