From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | * Neustradamus * <neustradamus(at)hotmail(dot)com> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Jacob Champion <jchampion(at)timescale(dot)com> |
Subject: | Re: RFC 9266: Channel Bindings for TLS 1.3 support |
Date: | 2022-07-29 05:44:47 |
Message-ID: | YuNzz767HkB79sys@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On Thu, Jul 28, 2022 at 08:33:50PM +0000, * Neustradamus * wrote:
> Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?
> - https://datatracker.ietf.org/doc/html/rfc9266
>
> Little details, to know easily:
> - tls-unique for TLS =< 1.2
tls-unique is not planned, as we have already tls-server-end-point for
TLS1.2 and Postgres requires a certificate, anyway.
> - tls-exporter for TLS = 1.3
>
> It is linked to:
> - https://github.com/postgres/postgres/search?q=tls-unique
So, tls-exporter has been made an official thing, finally. I was
wondering when this was going to happen. Jacob Champion has given me
a patch to support that, based on OpenSSL's SSL_export_keying_material()
to do the job. The base integration is not complicated, but I still
need to think a bit more about it when it comes to the min/max TLS
protocols we allow in libpq, for example, and polish the whole with
tests. We don't force any failures depending on the other connection
parameters for tls-server-end-point, so I suspect that we should be
fine with keeping things at their simplest.
I should be able to get something sent to the mailing lists for the
commit fest of September, so as we could have this feature in v16~.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Ajin Cherian | 2022-07-29 07:05:46 | Re: Excessive number of replication slots for 12->14 logical replication |
Previous Message | Tom Lane | 2022-07-28 21:26:27 | Re: Statistics updates is delayed when using `commit and chain` |