Compressão HTTP - HTTP compression

A compactação HTTP é um recurso que pode ser integrado a servidores e clientes da Web para melhorar a velocidade de transferência e a utilização da largura de banda.

Os dados HTTP são compactados antes de serem enviados do servidor: os navegadores compatíveis anunciarão quais métodos são compatíveis com o servidor antes de baixar o formato correto; navegadores que não oferecem suporte ao método de compactação compatível farão o download de dados descompactados. Os esquemas de compactação mais comuns incluem gzip e Brotli ; no entanto, uma lista completa de esquemas disponíveis é mantida pela IANA .

Existem duas maneiras diferentes de fazer a compactação em HTTP. Em um nível inferior, um campo de cabeçalho Transfer-Encoding pode indicar que a carga de uma mensagem HTTP está compactada. Em um nível superior, um campo de cabeçalho Content-Encoding pode indicar que um recurso que está sendo transferido, armazenado em cache ou referenciado de outra forma está compactado. A compactação usando Content-Encoding é mais amplamente suportada do que Transfer-Encoding, e alguns navegadores não anunciam suporte para compactação Transfer-Encoding para evitar o acionamento de bugs nos servidores.

Negociação de esquema de compressão

A negociação é feita em duas etapas, descritas no RFC 2616:

1. O cliente da web anuncia quais esquemas de compactação ele suporta, incluindo uma lista de tokens na solicitação HTTP . Para Content-Encoding , a lista está em um campo denominado Accept-Encoding ; para Transfer-Encoding , o campo é denominado TE .

GET /encrypted-area HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip, deflate

2. Se o servidor suportar um ou mais esquemas de compressão, os dados de saída podem ser comprimidos por um ou mais métodos suportados por ambas as partes. Se for esse o caso, o servidor adicionará um campo Content-Encoding ou Transfer-Encoding na resposta HTTP com os esquemas usados, separados por vírgulas.

HTTP/1.1 200 OK
Date: mon, 26 June 2016 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

O servidor web não é de forma alguma obrigado a usar qualquer método de compressão - isso depende das configurações internas do servidor web e também pode depender da arquitetura interna do site em questão.

Tokens de codificação de conteúdo

A lista oficial de tokens disponíveis para servidores e clientes é mantida pela IANA e inclui:

  • br - Brotli , um algoritmo de compressão projetado especificamente para codificação de conteúdo HTTP, definido no RFC 7932 e implementado em todos os principais navegadores modernos.
  • compress - método de programa UNIX "compress" (histórico; obsoleto na maioria dos aplicativos e substituído por gzip ou deflate)
  • deflate - compressão baseada no algoritmo deflate (descrito em RFC 1951), uma combinação do algoritmo LZ77 e codificação de Huffman, embrulhado dentro do formato de dados zlib (RFC 1950);
  • exi - W3C Efficient XML Interchange
  • gzip - Formato GNU zip (descrito em RFC 1952). Usa o algoritmo deflate para compactação, mas o formato de dados e o algoritmo de checksum diferem da codificação de conteúdo "deflate". Este método é o mais amplamente suportado em março de 2011.
  • identidade - nenhuma transformação é usada. Este é o valor padrão para codificação de conteúdo.
  • pack200-gzip - Formato de transferência de rede para arquivos Java
  • zstd - compressão padrão Z , definida em RFC 8478

Além disso, vários tokens não oficiais ou não padronizados são usados ​​livremente por servidores ou clientes:

  • bzip2 - compressão baseada no formato bzip2 gratuito, suportado por lighttpd
  • lzma - compressão baseada em (bruto) LZMA está disponível no Opera 20, e em elinks através de uma opção de tempo de compilação
  • peerdist - Caching e recuperação de conteúdo entre pares da Microsoft
  • rsync - codificação delta em HTTP , implementada por um par de proxies rproxy .
  • xpress - Protocolo de compactação da Microsoft usado pelo Windows 8 e posterior para atualizações de aplicativos da Windows Store. Compressão baseada em LZ77 opcionalmente usando uma codificação Huffman.
  • xz - compressão de conteúdo baseada em LZMA2, suportada por um patch não oficial do Firefox; e totalmente implementado no mget desde 2013-12-31.

Servidores que suportam compressão HTTP


A compactação em HTTP também pode ser obtida usando a funcionalidade de linguagens de script do lado do servidor, como PHP , ou linguagens de programação, como Java .

Problemas que impedem o uso de compressão HTTP

Um artigo de 2009 dos engenheiros do Google Arvind Jain e Jason Glasgow afirma que mais de 99 pessoas-ano são perdidas diariamente devido ao aumento no tempo de carregamento da página quando os usuários não recebem conteúdo compactado. Isso ocorre quando o software antivírus interfere nas conexões para forçá-las a serem descompactadas, onde proxies são usados ​​(com navegadores da Web excessivamente cautelosos), onde os servidores estão configurados incorretamente e onde os bugs do navegador impedem o uso da compactação. O Internet Explorer 6, que cai para HTTP 1.0 (sem recursos como compactação ou pipelining) quando está atrás de um proxy - uma configuração comum em ambientes corporativos - era o navegador principal mais sujeito a failback para HTTP descompactado.

Outro problema encontrado ao implantar a compactação HTTP em grande escala é devido à definição de codificação deflate : enquanto HTTP 1.1 define a codificação deflate como dados compactados com deflate (RFC 1951) dentro de um fluxo formatado zlib (RFC 1950), servidor Microsoft e produtos clientes historicamente implementou-o como um fluxo esvaziado "bruto", tornando sua implantação não confiável. Por esse motivo, alguns softwares, incluindo o servidor Apache HTTP, implementam apenas a codificação gzip .

Implicações de segurança

A compactação permite que uma forma de ataque de texto simples escolhido seja executada: se um invasor pode injetar qualquer conteúdo escolhido na página, ele pode saber se a página contém o conteúdo fornecido observando o aumento de tamanho do fluxo criptografado. Se o aumento for menor do que o esperado para injeções aleatórias, significa que o compressor encontrou uma repetição no texto, ou seja, o conteúdo injetado se sobrepõe à informação secreta. Esta é a ideia por trás do CRIME.

Em 2012 , foi anunciado um ataque geral ao uso de compressão de dados, denominado CRIME . Embora o ataque CRIME possa funcionar com eficácia contra um grande número de protocolos, incluindo, mas não se limitando a TLS e protocolos de camada de aplicativo, como SPDY ou HTTP, apenas explorações contra TLS e SPDY foram demonstradas e amplamente mitigadas em navegadores e servidores. A exploração CRIME contra a compactação HTTP não foi mitigada, embora os autores do CRIME tenham alertado que essa vulnerabilidade pode ser ainda mais disseminada do que a compactação SPDY e TLS combinadas.

Em 2013, uma nova instância de ataque CRIME contra compressão HTTP, apelidada de BREACH, foi publicada. Um ataque BREACH pode extrair tokens de login, endereços de e-mail ou outras informações confidenciais do tráfego da web criptografado por TLS em apenas 30 segundos (dependendo do número de bytes a serem extraídos), desde que o invasor engane a vítima para que visite um link da web malicioso. Todas as versões de TLS e SSL estão em risco de BREACH, independentemente do algoritmo de criptografia ou cifra usado. Ao contrário das instâncias anteriores de CRIME , que podem ser evitadas com sucesso desativando a compactação TLS ou a compactação de cabeçalho SPDY, o BREACH explora a compactação HTTP que não pode ser desligada de forma realista, pois praticamente todos os servidores da web dependem dela para melhorar a velocidade de transmissão de dados para os usuários.

A partir de 2016, o ataque TIME e o ataque HEIST agora são de conhecimento público.

Referências

links externos