TLSを復号化してから、BEASTまたはCRIMEに対して脆弱なOpenSSLで暗号化する場合の脆弱性はありますか？
次のTLSプロキシが存在すると仮定します
User <-----> Load Balancer that decrypts, encrypts <------> WebServer
Webサーバーが脆弱なバージョンのOpenSSLを実行している場合。
ロードバランサーへの最初のリンクが安全であると仮定して、TLSまたはBeastに対して脆弱な場合、ユーザーはWebサーバーを悪用できますか？
BEASTは、サーバーではなく、clientの脆弱性です。サーバーは「BEASTに対して脆弱」ではなく、かつてない。 「SSLサーバーをテストする」ツールについては混乱があり、サーバーが脆弱なクライアントの修正に失敗した場合、つまりクライアントが脆弱な場合、「BEASTの脆弱性」を報告する可能性がありますおよびそのClientHelloは、CBCモードでブロック暗号を使用する暗号スイートを使用することを好みます。およびは、脆弱性のない暗号スイート（RC4など）の使用を受け入れることも示しています。 、thenサーバーは、クライアントの設定に関係なく、非CBC暗号スイートを選択することでクライアントを保存する可能性があります。サーバーがこれを行わない場合、SSLテストツールは「BEASTに対して脆弱」と報告しますが、脆弱性はサーバーではなくクライアントにあります。
そうは言っても、BEASTとCRIMEはどちらも、攻撃者が次のすべてを実行できる使用状況に依存しています。
攻撃者は、暗号化されるデータの一部と、攻撃者が非常に関心を持っているいくつかの秘密データ（通常、HTTP Cookie）を選択できます。
攻撃者は暗号化された結果を見ることができます。
ポイント2から取得した情報は、ポイント1に使用できます。攻撃は適応です。
あなたの場合、これは攻撃者がロードバランサーとWebサーバー間の通信を盗聴できることを必要としますそしてロードバランサーによって暗号化されるデータを選択できます。ロードバランサーは、復号化したばかりのデータをユーザーから直接暗号化するため、BEASTとCRIMEの概念が適用されます。これは、データがユーザーのブラウザーからロードバランサーにどのように伝達されるかに関係なく当てはまります。その特定のTLSは、ユーザーとロードバランサーの間で転送中のデータを保護しますが、攻撃は実際にはロードバランサーとWebサーバーの間の接続、つまり最初のTLSの範囲外です。
次の理由により、攻撃者にとっては依然として困難な状況になります。
攻撃者が自分のデータをプレーンテキストストリームに挿入し、暗号化された結果を観察することができる通常の方法は、偽のWiFiアクセスポイントを使用することです。ただし、あなたの状況では、攻撃者はクライアント側に悪意のあるJavaScriptを何らかの方法で挿入する必要があります（したがって、ネットワーク的にはユーザーの近くにいる必要があります）が、ロードバランサーとWebサーバーの間の内部ネットワーク上のものも監視する必要があります。攻撃者は一度に2か所にいる必要があります。
BEASTは機能しなくなりました。攻撃を適用するには、攻撃者はプレーンテキストストリームに追加するバイトをかなり細かく制御する必要があります。単なるHTTPヘッダーでは不十分です。ここでは、クライアント上で、つまりユーザーのブラウザのコンテキスト内で実行される悪意のあるコードについて話していることに注意してください。 BEASTの作成者は、Javaホール、またはWebSocketのドラフト実装を使用して、ストリームにバイトをプッシュする2つの方法を見つけました。両方のホールは数年前からブラウザーで修正されています。
BEASTがまだ機能していても、ロードバランサーを通過するのに問題がある可能性があります。攻撃者の追加入力の微調整はHTTPリクエストと互換性がありません。物事はそれよりも少し低レベルでなければなりません。
ただし、CRIMEは問題なく通過します。