On Mon, May 20, 2024 at 9:09 PM Andrey M. Borodin <x4...@yandex-team.ru> wrote:
> > > > > On 20 May 2024, at 23:37, Robert Haas <robertmh...@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/>
