Re: libpq compression (part 3)

On Mon, May 20, 2024 at 9:09 PM Andrey M. Borodin <x4mmm@yandex-team.ru>
wrote:

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

That used to be the case in HTTP/1. But header compression was one of the
headline features of HTTP/2, which isn't exactly new anymore. But there's a
special algorithm, HPACK, for it. And then http/3 uses QPACK.
Cloudflare has a pretty decent blog post explaining why and how:
https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/, or
rfc7541 for all the details.

tl;dr; is yes, let's be careful not to expose headers to a CRIME-style
attack. And I doubt our connections has as much to gain by compressing
"header style" fields as http, so we are probably better off just not
compressing those parts.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>