Re: libpq compression (part 3) - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: libpq compression (part 3)
Date
Msg-id 5E6AC478-553A-45C8-BA21-7B513D1B4176@yandex-team.ru
Whole thread Raw
In response to Re: libpq compression (part 3)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: libpq compression (part 3)
List pgsql-hackers


> On 20 May 2024, at 23:37, Robert Haas <robertmhaas@gmail.com> wrote:
>
>  But if that's a practical
> attack, preventing compression prior to the authentication exchange
> probably isn't good enough: the user could also try to guess what
> queries are being sent on behalf of other users through the same
> pooled connection, or they could try to use the bits of the query that
> they can control to guess what the other bits of the query that they
> can't see look like.

All these attacks can be practically exploited in a controlled environment.
That's why previous incarnation of this patchset [0] contained a way to reset compression context. And Odyssey AFAIR
didit (Dan, coauthor of that patch, implemented the compression in Odyssey). 
But attacking authentication is much more straightforward and viable.

> On 20 May 2024, at 23:37, Robert Haas <robertmhaas@gmail.com> wrote:
>
> But, does this mean that we should just refuse to offer compression as
> a feature?

No, absolutely, we need the feature.

> I guess I don't understand why TLS removed
> support for encryption entirely instead of disclaiming its use in some
> appropriate way.

I think, the scope of TLS is too broad. HTTPS in turn has a compression. But AFAIK it never compress headers.
IMO we should try to avoid compressing authentication information.


Best regards, Andrey Borodin.

[0] https://commitfest.postgresql.org/38/3499/


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: First draft of PG 17 release notes
Next
From: Jacob Champion
Date:
Subject: Re: libpq compression (part 3)