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@timescale.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
