☰

Apache で SSLCompression をオフにできませんか?

tag-icon • tag-icon ssl apache-2.4 compression gzip
Apache で SSLCompression をオフにできませんか?

私のApacheは2.4.46で、OpenSSLバージョン1.1.1fを使用しています。

ディレクティブを設定しましたSSLCompression Off。有効にしても、SSL 圧縮はサポートされていないと表示されますが、これは良いことだと思います。

しかし、Firefox を使用して Web ページの 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心配です。

しかし、PHP でこのスクリプトを使用して cURL を使用してページを取得した場合でも、

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 のバグでしょうか??

アップデート：

Chrome でも発生します。

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

あなたの質問に答えるには、背景について少し知っておくと役に立ちます。

背景 - 圧縮を使用するとセキュリティ上のリスクが生じる可能性があるのはなぜですか?

いわゆる「圧縮サイド チャネル攻撃」がいくつかありますが、これは基本的に圧縮結果を使用して元のテキストを推測しようとするものです。それぞれの攻撃は基本的に、入力に圧縮を追加して出力を観察することで機能します。これは、多くの圧縮アルゴリズムが、テキスト全体を複数回繰り返すのではなく、繰り返されるテキストを認識して参照に置き換えることで機能するためです。これにより、メッセージは小さくなりますが、攻撃の機会が生まれます。

これらの攻撃はどのように機能するのでしょうか?

基本的に、秘密部分の一部またはすべてを推測し、それを未知の秘密部分とともにメッセージに追加し、暗号化された結果のサイズを観察します。特定の推測でサイズが小さくなる場合は、メッセージの一部が繰り返されているため、より高い圧縮の恩恵を受けていることになります。

何度か推測すれば、秘密の部分を解明することができます。これを行うには、メッセージに追加できる必要がありますが、これを行うにはさまざまな方法があります。たとえば、tokenexample.com に設定されている Cookie を知りたい場合は、メッセージ (まったく関係のないサイトにアクセスしたときに発生する非表示の XHR メッセージなど) を に送信し、example.com?token=1結果のメッセージ サイズを測定します (ブラウザーは自動的に Cookie をメッセージにも追加するため)。次に、example.com?token=2サイズが大きくなったか、小さくなったか、同じになったかを確認します。すべての可能な値に対してこれを繰り返し、メッセージが小さくなる Cookie の最初の文字を見つけます。この例では、 だとしますtoken=5。次に、2 番目の文字 ( など) を試します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 を使用する本当の理由はありませんでしたが、これが本当の理由となりました。ないSSL/TLS圧縮は常にオフにして、次のようなツールを使用する必要があります。SSLラボこれを確認するには、ほとんどのサーバーではデフォルトでオフになっており、しばらくその状態が続いているため、オンになっていたら非常に驚くでしょう。

HTTP ボディ圧縮

HTTPボディレベルでの圧縮はより興味深いものです。これは通常gzipまたは新しいBrotliアルゴリズムを使用し、はほとんどの場合、ウェブパフォーマンスの向上が顕著であるため、オンにすることをお勧めします。これは、HTTPボディ（特にレスポンスボディ）がしばしば大きく、ネットワークが比較的遅いためです。そのため、ネットワークを介して小さなサイズを送信すると、実際にメリットがあります。確かに、理論上は、同様の攻撃（いわゆる侵入攻撃そしてまた時間（バリエーション） — ただし、秘密データが本文に再度含まれている場合のみです（したがって、同一の推測は圧縮後に小さくなる可能性があります）。ほとんどの応答には秘密データが含まれていないため（たとえば、最後にページの画面に Cookie が印刷されたのを見たのはいつですか？）、リスクははるかに小さくなりますが、ヘッダー内の Cookie は常に含まれており、メッセージの大きな部分を占めることがよくあります。

もちろん、画面に印刷される秘密情報（名前、社会保障番号、生年月日、銀行口座の詳細など）がある場合は、脆弱である可能性があり、それらの応答をHTTP圧縮しないことを検討する必要があるかもしれませんが、それらはかなり異例なので、HTTP圧縮を無効にする必要があります。毎応答が正しい答えになることはめったにありません。画面に秘密情報を表示する場合でも、より良いオプションがあります。たとえば、そのデータを画面にまったく表示しない、または少なくとも完全に表示しない (最後の 4 桁以外はすべて星で囲むなど)、ユーザーの応答データが同時に画面に表示されないようにする、データをランダムな文字で埋め込む、レート制限を追加するなどのオプションが、通常ははるかに優れています。

質問に戻ります

それで、あなたの質問に答えると、SSL圧縮とHTTPボディ圧縮は2つの異なるものであり、前者はオフそして後者の上(ただし、メリットがあるにもかかわらず、リスクを負いたくない非常に安全なアプリケーションの場合は除きます。ただし、その場合でも、通常はこれを処理するより良い方法があります)。

最後に、HTTPヘッダー圧縮に関するボーナス情報を紹介します。

最後に、HTTP ヘッダーの圧縮についてお話しします。前述のとおり、HTTP ヘッダーには攻撃者が価値があると考える Cookie の秘密が含まれていることが多いためです。

ごく最近まで主流のバージョンであった HTTP/1.1 では、これが許可されていなかったため、ここで説明する内容はあまりありませんでした。これらは、完全に圧縮されていない形式で送信されたため (ただし、HTTPS が使用されている場合は SSL/TLS を使用して暗号化されます)、サイド チャネル圧縮のリスクに対して脆弱ではありませんでした (SSL 圧縮が使用されていないと仮定)。

これらは通常、HTTP 本文に比べて非常に小さいため、圧縮しすぎることについて心配する人はいませんでした。しかし、Web ページを構成するために使用されるリソースの数が増えると (最近では 100 を超えることも珍しくありません)、ほぼ同じ HTTP ヘッダーを常に送受信することで冗長性が大幅に増加します (たとえば、すべてのリクエストで送信されるが、すべてのリクエストで変更されないユーザー エージェント ヘッダーのサイズを確認したことがありますか)。

そのため、新しい HTTP/2 と、まもなくリリースされる HTTP/3 プロトコルでは、HTTP ヘッダーの圧縮が許可されていますが、これらの攻撃に対して脆弱ではない圧縮アルゴリズム (HTTP/2 の場合は HPACK、HTTP/3 の場合は同様の QPACK) が明示的に選択されています。ちなみに、これは明示的な選択でした。HTTP/2 のベースとなっている以前の SPDY プロトコルは gzip を使用していたため、脆弱だったためです。そのため、そのことが指摘されたときに、HTTP/2 への標準化の一環として変更する必要がありました。

常に「安全な圧縮」を使用しないのはなぜですか?

では、なぜ安全な圧縮技術 (HPACK や QPACK など) を HTTP レスポンス本文にも使用して、この問題を回避できないのでしょうか。これらは、辞書や既知の繰り返し値を使用する非常に特殊な圧縮技術です。これは、値が少なく、繰り返しが多い HTTP ヘッダーには有効ですが、応答ごとに完全に異なる可能性のある、より汎用的な HTTP 本文応答には適していません。

これでいくつかのことが説明され、あなたの質問への答えになったと思います。

答え2

犯罪に対する攻撃2012-4929 の脆弱性暗号化されていないデータの長さを適切に難読化せずに圧縮されたヘッダーを暗号化することで、プレーンテキストのヘッダーを（推測によって）明らかにすることが可能になります。

あなたの状況では、コンテンツは圧縮され、圧縮されたデータのサイズ (長さ) が別のヘッダーとして追加され、すべてが暗号化されます。暗号化されていないデータの長さは決して明らかにされないため、CRIME 攻撃に対して脆弱ではありません。

関連情報