On Tue, Sep 20, 2022 at 11:51:44AM -0700, Jacob Champion wrote: > On Tue, Sep 20, 2022 at 11:01 AM Jacob Champion <jchamp...@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
signature.asc
Description: PGP signature
