Re: libpq compression (part 3)
От | Andrey M. Borodin |
---|---|
Тема | Re: libpq compression (part 3) |
Дата | |
Msg-id | 5E6AC478-553A-45C8-BA21-7B513D1B4176@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: libpq compression (part 3) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: libpq compression (part 3)
|
Список | 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 по дате отправления: