Compressão HTTP - HTTP compression
HTTP |
---|
Métodos de solicitação |
Campos de cabeçalho |
Códigos de status de resposta |
Métodos de controle de segurança de acesso |
Vulnerabilidades de segurança |
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
- SAP NetWeaver
- Microsoft IIS : integrado ou usando módulo de terceiros
- Servidor Apache HTTP , via mod_deflate (apesar do nome, apenas com suporte a gzip) e mod_brotli
- Servidor Hiawatha HTTP : fornece arquivos pré-compactados
- Servidor HTTP Cherokee , compressões gzip e deflate em tempo real
- Oracle iPlanet Web Server
- Zeus Web Server
- lighttpd
- nginx - integrado
- Aplicativos baseados em Tornado , se "compress_response" estiver definido como True nas configurações do aplicativo (para versões anteriores a 4.0, defina "gzip" como True)
- Jetty Server - serviço de conteúdo estático padrão integrado e disponível por meio de configurações de filtro de servlet
- GeoServer
- Apache Tomcat
- IBM Websphere
- AOLserver
- Ruby Rack , por meio do middleware Rack :: Deflater
- HAProxy
- Verniz - embutido. Funciona também com ESI
- Armeria - Servindo arquivos pré-compactados
- NaviServer - compressão integrada, dinâmica e estática
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
- RFC 2616: Protocolo de Transferência de Hipertexto - HTTP / 1.1
- Valores de codificação de conteúdo HTTP por autoridade de números atribuídos da Internet
- Compressão com lighttpd
- Horror da codificação: compactação HTTP no IIS 6.0
- 15 segundos: compactação do site na máquina de retorno (arquivado em 16 de julho de 2011)
- Compressão HTTP : página de recursos do fundador da VIGOS AG, Constantin Rack
- Usando compactação HTTP por Martin Brown do Server Watch
- Usando compressão HTTP em PHP
- Compressão HTTP dinâmica e estática com Apache httpd