HTTPSのBrotli圧縮
Chrome、Firefox、そして間もなくEdgeは、新しいBrotli圧縮アルゴリズムをHTTPSでのみサポートするようです。
この新しい圧縮アルゴリズムがBREACH攻撃の影響を受けやすいかどうかはわかりません。私が見つけた唯一の関連するものは RFC 7932のセクション12 の最後にありました：
暗号化されたチャネルを介して圧縮データを送信するシステムに対する攻撃の可能性は次のとおりです。任意の（攻撃者が提供した）データを秘密データ（パスワード、Cookie）と繰り返し混合し、暗号文の長さを観察できる攻撃者は、秘密データを再構築できる可能性があります。この種の攻撃から保護するために、アプリケーションは機密データと機密ではない、攻撃者が提供する可能性のあるデータを同じ圧縮ストリームに混在させないでください。
その段落から、ブロトリは依然として侵害の影響を受けやすいように見えます。 BREACH（および関連するCRIME攻撃）についての私の理解が正しい場合、HTTPSを介した圧縮は安全ではありません。
この場合、HTTPSコンテンツにBrotliを使用しても安全ですか？そうでない場合、ブラウザベンダーがそれをサポートしているのはなぜですか？
hTTPSを介した新しいBrotli圧縮アルゴリズムのみをサポートします。
理論的にはそうです。実際には、Chromeは、プレーンHTTPでのbrotliのサポートをアナウンスしていませんが、現時点ではプレーンHTTPでもbrotli圧縮回答を受け入れます。FirefoxはHTTPSでの回答のみをサポートします。
BREACH（および関連するCRIME攻撃）についての私の理解が正しい場合、HTTPSを介した圧縮は安全ではありません。
これは間違った一般化です。 BREACH攻撃は、攻撃者が推測したいCSRFトークンなどの秘密情報を含む動的コンテンツにのみ影響します。入力されたフォームから反映されたデータの場合のように、攻撃者が自分のデータを元のコンテンツに反映できる場合にのみ機能します。また、攻撃者は、圧縮されたコンテンツのサイズの変化を検出できる必要があります。つまり、接続のパッシブスニッフィング（クラシックBREACH攻撃）を使用するか、タイミング（ HEIST攻撃 ）を介して検出できる必要があります。反映が不可能なコンテンツや、攻撃者が推測したい秘密を含まないコンテンツを圧縮することは、依然として安全です。これは特に、静的コンテンツの圧縮が安全であることを意味します。
CRIME攻撃については、現在のブラウザがすでに行っているTLSレベルの圧縮を無効にするだけで十分です。 CRIMEはHTTPSでのコンテンツ圧縮とは何の関係もありません。
また、参照 TLSを介したコンテンツのgzippingが許可されています 。