☰

Не можете отключить SSLCompression в Apache?

tag-icon • tag-icon ssl apache-2.4 compression gzip
Не можете отключить SSLCompression в Apache?

Мой Apache — 2.4.46, использующий Openssl версии 1.1.1f.

Я установил директиву SSLCompression Off. Даже если я включаю ее, он говорит, что SSL-сжатие не поддерживается, что, я думаю, хорошо.

Но когда я использую Firefox для просмотра HTTP-заголовков веб-страницы, я вижу следующие заголовки ответа:

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

То, что говорит: content-encoding: gzipбеспокоит меня.

Но даже если я использую cURL для извлечения страницы с помощью этого скрипта на 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");

Он возвращает следующие 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

Что меня сбивает с толку. Я даже очистил кэш в Firefox, но безуспешно. Я не хочу быть уязвимым для атаки CRIME. В свою очередь, я мог бы просто полностью отключить gzip. Но прежде чем я это сделаю, я хочу узнать, почему это происходит. Может быть, ошибка в Firefox??

Обновлять:

Это также происходит в хроме.

Конфигурация 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>

решение1

Чтобы ответить на ваш вопрос, полезно немного узнать о предыстории:

Предыстория — почему использование сжатия потенциально несет риск безопасности?

Существует несколько так называемых «атак по побочным каналам сжатия», которые в основном используют результаты сжатия, чтобы попытаться угадать исходный текст. Каждая из них работает, в основном, за счет возможности добавлять входные данные к сжатию и затем наблюдать за выходными данными. Это связано с тем, что многие алгоритмы сжатия работают, распознавая повторяющийся текст и заменяя его ссылками, а не повторяя текст полностью несколько раз. Это приводит к меньшим сообщениям, но открывает возможность для атаки.

Как работают эти атаки?

По сути, если вы угадаете часть или всю секретную часть, добавите ее к сообщению вместе с неизвестной секретной частью, а затем посмотрите на размер зашифрованного результата, и если он станет меньше при определенных догадках, то, должно быть, вы повторили часть сообщения, поэтому получили выгоду от более высокого сжатия.

С помощью нескольких догадок можно вычислить секретную часть. Это зависит от возможности добавлять к сообщению, но есть различные методы сделать это. Например, если вы хотите узнать набор tokencookie для example.com, то отправьте сообщение (возможно, скрытое сообщение XHR, которое появляется, когда люди посещают ваш совершенно не связанный сайт?) example.com?token=1и измерьте размер полученного сообщения (поскольку браузер автоматически добавит cookie к сообщению). Затем попробуйте example.com?token=2посмотреть, больше ли оно, меньше или такое же. Повторите это для всех возможных значений, пока не найдете первый символ cookie, где сообщение будет меньше. Допустим, в этом примере это token=5. Затем попробуйте второй символ (например example.com?token=51, example.com?token=52... и т. д.). Повторяйте, пока не получите полный cookie.

Вы можете либо измерить длину сообщения напрямую (например, наблюдая за зашифрованными сообщениями, если вы можетеЧеловек посерединесети) или засеките время, необходимое для отправки сообщения, чтобы сделать точную оценку его длины.

HTTP-сообщения можно сжимать несколькими способами

Сжатие может происходить на разных уровнях HTTP-сообщения: 1) на уровне SSL/TLS, 2) на уровне тела HTTP-сообщения и 3) на уровне заголовка HTTP.

SSL-сжатие

Сжатие SSL/TLS в основном происходит независимо от того, что это HTTP-сообщение, оно выполняется на уровне SSL/TLS. Такие атаки, какПРЕСТУПЛЕНИЕВ основном мы не смогли использовать сжатие SSL/TLS, потому что оно ввело слишком много способов угадать скрытые части сообщения, в основном используя вышеуказанный алгоритм. Честно говоря, преимущества сжатия SSL/TLS в любом случае были не такими уж большими, особенно если мы уже сжали тело ответа на базовом уровне HTTP с помощью gzip или чего-то подобного, поэтому повторное сжатие после шифрования на самом деле не сохранило намного больше данных. Так что нет реальной причины использовать его, и это дало реальную причинуНЕТчтобы использовать его. Сжатие SSL/TLS всегда должно быть отключено и используйте такой инструмент, какSSLLabsчтобы подтвердить это. По умолчанию он выключен на большинстве серверов и был выключен уже некоторое время, так что я был бы очень удивлен, если бы он был включен.

Сжатие HTTP-тела

Сжатие на уровне HTTP Body более интересно. Обычно оно использует gzip или более новый алгоритм Brotli иЯВЛЯЕТСЯрекомендуется включать в большинстве случаев, так как прирост производительности сети значителен. Это связано с тем, что HTTP-тела часто большие (конкретные тела ответов), а сети обычно относительно медленные — поэтому есть реальные преимущества в отправке меньших размеров по сети. Теперь да, в теории это уязвимо для подобных атак (так называемыхатака BREACHа такжеВРЕМЯвариант) — но только если секретные данные снова находятся в теле (поэтому любая идентичная догадка может оказаться меньше после сжатия). Таким образом, риск намного меньше, поскольку большинство ответов не включают секретные данные (например, когда вы в последний раз видели свой файл cookie напечатанным на экране на странице?), тогда как файлы cookie в заголовках часто всегда включены и составляют большую часть сообщения.

Конечно, если у вас есть какая-то секретная информация, которая выводится на экран (ваше имя, номер социального страхования, дата рождения, банковские реквизиты и т. д.), то она может быть уязвима и, возможно, стоит подумать об отказе от HTTP-сжатия этих ответов, но они довольно нетипичны, поэтому отключите HTTP-сжатие длякаждыйОтвет редко бывает правильным ответом. Даже когда вы представляете секретную информацию на экране, есть лучшие варианты: например, не показывать эти данные на экране вообще или, по крайней мере, полностью (например, зачеркнуть все, кроме последних 4 цифр), не позволять данным ответа пользователя отображаться на экране одновременно, дополнять данные случайными символами или добавлять ограничение скорости — обычно это гораздо лучшие варианты, например.

Вернемся к вашему вопросу

Итак, отвечая на ваш вопрос, сжатие SSL и сжатие тела HTTP — это две разные вещи, и первое должно бытьвыключенныйи последнийна(за исключением действительно безопасных приложений, которые не хотят рисковать, несмотря на выгоды — но даже в этом случае обычно есть лучшие способы справиться с этой проблемой).

В завершение — дополнительная информация о сжатии HTTP-заголовков.

Чтобы завершить рассказ, давайте поговорим о сжатии заголовков HTTP, поскольку, как уже упоминалось выше, они часто содержат секретные данные cookie, которые злоумышленники могут посчитать ценными.

HTTP/1.1, который до недавнего времени был преобладающей версией в использовании, не позволял этого, так что здесь не о чем было особо говорить. Они были отправлены в полностью несжатом виде (хотя и зашифрованном с помощью SSL/TLS, если использовался HTTPS) и поэтому не подвержены рискам сжатия по сторонним каналам (предполагая, что сжатие SSL не использовалось).

Они также обычно были очень маленькими по сравнению с HTTP Bodies, поэтому никто не беспокоился об их слишком большом сжатии. Однако с увеличением количества ресурсов, используемых для создания веб-страницы (более 100 в настоящее время не является чем-то необычным), возникает много избыточности при отправке практически одних и тех же HTTP Headers туда и обратно все время (вы видели размер заголовка User Agent, например, который отправляется с каждым отдельным запросом, но никогда не меняется для всех этих запросов?).

Так что более новые протоколы HTTP/2 и HTTP/3, которые скоро будут выпущены, позволяют сжатие заголовков HTTP, но они специально выбирают алгоритм сжатия (HPACK для HTTP/2 и аналогичный QPACK для HTTP/3), который не уязвим для этих атак. Это был явный выбор, кстати, потому что более ранний протокол SPDY, на котором был основан HTTP/2, использовал gzip и поэтому был уязвим. Так что когда это было отмечено, его пришлось изменить в рамках стандартизации для HTTP/2.

Почему бы не использовать всегда «безопасное сжатие»?

Так почему же мы не можем использовать безопасные методы сжатия (например, HPACK или QPACK) для тел HTTP-ответов и избегать этого? Что ж, это очень специфические методы сжатия, которые используют словари или известные и повторяющиеся значения. Это хорошо работает для HTTP-заголовков, где мало значений, и которые часто повторяются, но это не совсем вариант для более общих ответов HTTP-тела, которые, скорее всего, будут полностью отличаться каждый ответ.

Надеюсь, это кое-что прояснит и ответит на ваш вопрос.

решение2

ПРЕСТУПНОЕ нападение противCVE-2012-4929заключается в шифровании сжатых заголовков без надлежащего сокрытия длины незашифрованных данных, что позволяет раскрыть заголовки открытого текста (путем угадывания).

В вашей ситуации содержимое сжимается, размер (длина) сжатых данных добавляется как еще один заголовок, а затем все это шифруется. Это не уязвимо для атаки CRIME, поскольку длина незашифрованных данных никогда не раскрывается.

Связанный контент