Não é possível desligar o SSLCompression no Apache?

Question

Meu Apache é 2.4.46 e está usando Openssl versão 1.1.1f

Eu defini a diretriz SSLCompression Off. Mesmo se eu habilitá-lo, diz que a compactação SSL não é suportada, o que é bom, eu acho.

Mas, quando uso o Firefox para ver os cabeçalhos HTTP da página da Web, vejo estes cabeçalhos de resposta:

HTTP/2 200 OK
date: Fri, 25 Dec 2020 12:13:58 GMT
server: Apache
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
vary: Accept-Encoding
content-encoding: gzip
content-length: 3299
content-type: text/html; charset=UTF-8
X-Firefox-Spdy: h2

Aquilo que diz: content-encoding: gzipme preocupa.

Mas, mesmo que eu use cURL para buscar a página usando este script em PHP:

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
//enable headers
curl_setopt($ch, CURLOPT_HEADER, 1);
//get only headers
curl_setopt($ch, CURLOPT_NOBODY, 1);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 5000);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_0);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0");
curl_setopt($ch, CURLOPT_ENCODING, "gzip");

Ele retorna estes cabeçalhos HTTP:

HTTP/2 200 
date: Fri, 25 Dec 2020 12:16:45 GMT
server: Apache
set-cookie: __Secure-CCJRLSESSID=g7m99kljvea2g5uk58f5lfskr1; path=/; secure; HttpOnly; SameSite=Lax
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
content-type: text/html; charset=UTF-8

O que me confunde. Até limpei o cache no Firefox, mas sem sorte. Não quero ficar vulnerável ao ataque CRIME. Por sua vez, eu poderia simplesmente desabilitar completamente o gzip. Mas antes de fazer isso, quero saber por que isso acontece. Talvez um bug no Firefox?

Atualizar:

Isso também acontece no Chrome.

configuração mod_deflate:

SSLCompression Off
<IfModule deflate_module>
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml
</IfModule>

Answer 1

Para responder à sua pergunta, é útil saber um pouco sobre o histórico:

Histórico - por que o uso da compactação é potencialmente um risco à segurança?

Existem alguns chamados “ataques de canal lateral de compressão” que basicamente usam resultados de compressão para tentar adivinhar o texto original. Cada um funciona basicamente sendo capaz de adicionar a entrada à compactação e depois observar a saída. Isso ocorre porque muitos algoritmos de compactação funcionam reconhecendo textos repetidos e substituindo-os por referências, em vez de repetir o texto completo várias vezes. Isto leva a mensagens menores, mas abre uma oportunidade de ataque.

Como funcionam esses ataques?

Basicamente, se você adivinhar parte ou toda a parte secreta, adicioná-la à mensagem junto com a parte secreta desconhecida e, em seguida, observar o tamanho do resultado criptografado e se ele ficar menor com certas suposições, então você deve ter repetido parte de a mensagem se beneficiou muito de uma compactação mais alta.

Com alguns palpites é possível descobrir a parte secreta. Fazer isso depende da capacidade de adicionar itens à mensagem, mas existem vários métodos para fazer isso. Por exemplo, se você quiser saber um tokenconjunto de cookies para example.com, envie uma mensagem (talvez uma mensagem XHR oculta que acontece quando as pessoas visitam seu site totalmente não relacionado?) example.com?token=1e meça o tamanho da mensagem resultante (já que o navegador adicionará automaticamente o cookie para a mensagem também). Em seguida, tente example.com?token=2ver se é maior, menor ou igual. Repita isso para todos os valores possíveis, até descobrir o primeiro caractere do cookie, onde a mensagem será menor. Digamos que neste exemplo seja token=5. Em seguida, tente o segundo caractere (por exemplo example.com?token=51, example.com?token=52... etc.). Repita até obter o biscoito completo.

Você pode medir o comprimento da mensagem diretamente (por exemplo, observando as mensagens criptografadas, se puder).Homem no meioa rede) ou cronometrar quanto tempo leva para enviar a mensagem, para adivinhar o comprimento.

Mensagens HTTP podem ser compactadas de várias maneiras

A compactação pode ocorrer em diferentes níveis em uma mensagem HTTP: 1) no nível SSL/TLS, 2) no nível do corpo HTTP e 3) no nível do cabeçalho HTTP.

Compressão SSL

A compactação SSL/TLS basicamente acontece independentemente do fato de haver uma mensagem HTTP por baixo - é feita no nível SSL/TLS. Ataques comoCRIMEbasicamente nos impediu de usar a compactação SSL/TLS porque introduziu muitas maneiras de adivinhar partes ocultas da mensagem, basicamente usando o algoritmo acima. Para ser honesto, os ganhos da compactação SSL/TLS não foram tão grandes de qualquer maneira, especialmente se já tivermos compactado a resposta do corpo no nível HTTP subjacente usando gzip ou similar, portanto, compactá-la novamente após criptografá-la não economizou muito mais dados. Portanto, não há motivo real para usá-lo, e isso deu um motivo realNÃOpara usá-lo. A compactação SSL/TLS deve sempre ser desativada e usar uma ferramenta comoSSLLabspara confirmar isso. Ele está desativado por padrão na maioria dos servidores e já existe há algum tempo, então ficaria muito surpreso se estivesse ativado.

Compressão de corpo HTTP

A compactação no nível do corpo HTTP é mais interessante. Isso normalmente usa gzip ou o algoritmo Brotli mais recente eÉrecomendado estar ativado na maioria dos casos, pois os ganhos no desempenho da web são significativos. Isso ocorre porque os corpos HTTP geralmente são grandes (órgãos de resposta específicos) e as redes geralmente são relativamente lentas — portanto, há ganhos reais no envio de tamanhos menores pela rede. Agora, sim, em teoria, isso é vulnerável a ataques semelhantes (os chamadosAtaque BREACHe também oTEMPOvariante) - mas apenas se os dados secretos estiverem no corpo novamente (portanto, qualquer suposição idêntica pode ser considerada menor após a compactação). Portanto, o risco é muito menor, pois a maioria das respostas não inclui dados secretos (por exemplo, quando foi a última vez que você viu seu cookie impresso na tela de uma página?), enquanto os cookies nos cabeçalhos geralmente são sempre incluídos e uma proporção maior da mensagem .

É claro que se você tiver alguma informação secreta impressa na tela (seu nome, número de seguro social, DoB, dados bancários... etc.), então ela pode ser vulnerável e talvez deva considerar não compactar HTTP essas respostas, mas elas são atípicas então desabilitar a compactação HTTP paratodoresposta raramente é a resposta certa. Mesmo quando você está apresentando informações secretas na tela, existem opções melhores: por exemplo, não apresentar esses dados na tela, ou pelo menos na íntegra (por exemplo, marcar todos os dados, exceto os últimos 4 dígitos), não permitir que os dados de resposta do usuário sejam mostrados na tela ao mesmo tempo, preencher os dados com caracteres aleatórios ou adicionar limitação de taxa geralmente são opções muito melhores, por exemplo.

De volta à sua pergunta

Então, para responder sua pergunta, Compressão SSL e Compressão Corporal HTTP são duas coisas diferentes e a primeira deveria serdesligadoe o últimosobre(exceto em aplicações realmente seguras que não querem arriscar isso, apesar dos ganhos — mas mesmo assim, geralmente existem maneiras melhores de lidar com isso).

Para finalizar, algumas informações extras sobre compactação de cabeçalho HTTP

Para finalizar a história, vamos falar sobre a compactação de cabeçalho HTTP porque, conforme acima, eles geralmente contêm segredos de cookies que os invasores considerariam valiosos.

HTTP/1.1 que, até muito recentemente, era a versão predominante em uso, não permitia isso, então não havia muito o que falar aqui. Eles foram enviados em formato totalmente descompactado (embora criptografados usando SSL/TLS se HTTPS fosse usado) e, portanto, não vulneráveis ​​a riscos de compactação de canal lateral (assumindo que a compactação SSL não foi usada).

Eles também eram normalmente muito pequenos em comparação com os corpos HTTP, então ninguém realmente se preocupava em compactá-los demais. No entanto, com o aumento no número de recursos usados ​​para compor uma página web (mais de 100 não é incomum hoje em dia), há muita redundância no envio de praticamente os mesmos cabeçalhos HTTP para frente e para trás o tempo todo (você viu o tamanho do cabeçalho do agente do usuário, por exemplo, que é enviado com cada solicitação, mas nunca muda para todas essas solicitações?).

Portanto, os protocolos HTTP/2 mais recentes e HTTP/3 prestes a serem lançados permitem a compactação de cabeçalho HTTP, mas escolhem especificamente um algoritmo de compactação (HPACK para HTTP/2 e o QPACK semelhante para HTTP/3) que não é vulnerável a esses ataques. Esta foi uma escolha explícita, porque o protocolo SPDY anterior no qual o HTTP/2 era baseado usava gzip e, portanto, era vulnerável. Então, quando isso foi sinalizado, ele teve que mudar como parte da padronização para HTTP/2.

Por que não usar sempre “compressão segura”?

Então, por que não podemos usar técnicas de compactação seguras (como HPACK ou QPACK) também para corpos de resposta HTTP e evitar isso? Bem, são técnicas de compressão muito específicas que utilizam dicionários ou valores conhecidos e repetidos. Isso funciona bem para cabeçalhos HTTP onde há poucos valores e que são repetidos muito, mas não é realmente uma opção para respostas de corpo HTTP de uso mais geral, que provavelmente serão completamente diferentes em cada resposta.

Espero que isso explique algumas coisas e responda à sua pergunta.

Answer 2

O ataque CRIME contraCVE-2012-4929trata-se de criptografar os cabeçalhos compactados sem ofuscar adequadamente o comprimento dos dados não criptografados, o que torna possível revelar cabeçalhos de texto simples (por adivinhação).

Na sua situação, o conteúdo é compactado, o tamanho (comprimento) dos dados compactados é adicionado como outro cabeçalho e tudo isso é criptografado. Isso não é vulnerável ao ataque CRIME, pois a extensão dos dados não criptografados nunca é revelada.