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-10-14 02:00:10 |
Message-ID: | Y0jCqr1chYoGhM40@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 13, 2022 at 10:30:37AM -0700, Jacob Champion wrote:
> Is the intent to backport tls-exporter client support? Or is the
> compatibility break otherwise acceptable?
Well, I'd rather say yes thanks to the complexity avoided in the
backend as that's the most sensible piece security-wise, even if we
always require a certificate to exist in PG. A server attempting to
trick a client in downgrading would still be a problem :/
tls-exporter would be a new feature, so backporting is out of the
picture.
> It seemed like there was also some general interest in proxy TLS
> termination (see also the PROXY effort, though it has stalled a bit).
> For that, I would think tls-server-end-point is an important feature.
Oh, okay. That's an argument in favor of not doing that, then.
Perhaps we'd better revisit the introduction of tls-exporter once we
know more about all that, and it looks like we would need a way to be
able to negotiate which channel binding to use (I recall that the
surrounding RFCs allowed some extra negotiation, vaguely, but my
impression may be wrong).
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2022-10-14 02:14:55 | Re: Use LIMIT instead of Unique for DISTINCT when all distinct pathkeys are redundant |
Previous Message | David Rowley | 2022-10-14 01:39:23 | Re: Incorrect comment regarding command completion tags |