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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: First draft of PG 17 release notes
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: libpq compression (part 3)