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-13 06:00:59 |
Message-ID: | Y0epm1mCHpwFQP3o@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 20, 2022 at 11:51:44AM -0700, Jacob Champion wrote:
> On Tue, Sep 20, 2022 at 11:01 AM Jacob Champion <jchampion(at)timescale(dot)com> wrote:
>> 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).
>
> To be more specific: I think I'm hitting the case that Heikki pointed
> out several years ago [1]:
>
>> The problematic case is when e.g. the server
>> only supports tls-unique and the client only supports
>> tls-server-end-point. What we would (usually) like to happen, is to fall
>> back to not using channel binding. But it's not clear how to make that
>> work, and still protect from downgrade attacks.
>
> The problem was deferred when tls-unique was removed. We might have to
> actually solve it now.
Right. One thing that would reduce the complexity of the equation is
to drop support for tls-server-end-point in the backend in PG >= 16 as
the versions of OpenSSL we still support on HEAD would cover
completely tls-exporter.
We should have in libpq the code to support both tls-server-end-point
and tls-exporter as channel bindings, for backward-compatibility. If
we were to drop support for OpenSSL 1.0.1, things get a bit easier
here, as we would be sure that channel binding is supported by all the
code paths of libpq. Having both channel_binding_type with
channel_binding=require would offer some protection against downgrade
attacks. That does not feel completely water-proof, still default
settings like sslmode=prefer are not really secure either..
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-10-13 06:12:57 | Re: Move backup-related code to xlogbackup.c/.h |
Previous Message | Pavel Stehule | 2022-10-13 05:41:32 | Re: Schema variables - new implementation for Postgres 15 |