AESを完全に無効にすることなくBEASTを軽減する方法はありますか？
TLS <= 1.0に対するBEAST攻撃からユーザーを保護する最も簡単な方法は、RC4を優先するか、他のすべての（CBC）暗号スイートを無効にすることです。のようなものを指定することによって
SSLCipherSuite RC4-SHA:HIGH:!ADH
apache mod_ssl構成。
ただし、CBCの問題はTLS> = 1.1で修正されたようです。 TLS 1.1または1.2をサポートすると主張するクライアントに対してこれらの暗号を（再度）有効にする方法はありますか？回避策があるようです：
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
これは、TLS> = 1.1でのみ使用可能な暗号スイートを指定することでトリックを実行します。これには、TLS> = 1.1クライアントが「古い」暗号スイートを使用できないようにするという副作用があるようです。
Mod_sslにTLS> = 1.1のCBCモード暗号を使用するように明示的に指示する方法は実際にはありませんが、SSL/TLS <= 1.0のRC4のみを使用しますか？これは、セキュリティと互換性の最適な組み合わせのようです。
BEASTを軽減する1つの方法は、何もしないことです。 BEASTで使用されている脆弱性はまだ存在していますが、悪用するのはかなり困難です。要求で送信されるデータを高度に制御しながら、クロスドメイン要求を実行する機能が必要です。特に、「バイナリ」データが必要です。 DuongとRizzoは、プレーンに対する攻撃をマッピングする方法を見つけられませんでした<img>タグ（このようなタグを生成する悪意のあるJavascript、攻撃者が選択したパス：パスはリクエストに含まれますが、テキストのみです）。デモでは、2つのクロスドメインホールを使用できます。1つはドラフトバージョンのWebSocketsで、もう1つはJavaのOracleでの実装です。両方のホールが修正されたため、正しい現在、BEASTはもう適用されていません（ブラウザを1年以上更新しなかった場合を除きます。その場合、おそらくより大きな問題が発生します）。
クロスドメインの脆弱性の非存在に依存することはせいぜい薄弱であるため、ブラウザーベンダーもレコード分割を使用していくつかの追加の対策を組み込んでいます。ブラウザは、nバイトのデータのブロックを1つのSSLレコードに入れるのではなく送信したい場合、それをtwoレコード、最初は非常に小さい。 SSL/TLSではレコード境界に意味上の意味がないため、意味を変更せずにこのような分割を行うことができます。ただし、各レコードは [〜＃〜] mac [〜＃〜] レコードデータおよびシーケンス番号に対して計算され、1つの最初の鍵交換から導出された鍵。これはどういうわけか、疑似乱数ジェネレータとして機能します。したがって、小さなレコードは、TLS 1.1+をBEASTから保護するランダムIV生成を「エミュレート」します。
理想的には、分割は0/nです。データのない（ただしMACのある）レコードの後に、実際のデータのレコードが続きます。長さゼロのレコードは許可されます（ 標準 に従って）が、バグのあるクライアントとサーバーの実装はそれらを許容しません（特にIE 6.0））;代わりに、ブラウザは1/n-1split、これはBEASTを倒すのと同じくらい良いですが、ほとんどすべての既存のSSL/TLSクライアントとサーバーでも機能します。少なくともChromeそしてFirefoxはそれをプッシュしました 昨年 。
優れたソリューションはTLS 1.1 +ですが、SSL 3.0およびTLS 1.0でも、少なくともWebコンテキストではBEASTの問題は修正済みと見なすことができます。したがって、AESを使用して、満足してください。
OpenSSLには ミストfor BEAST があり、これは0.9.6d以降デフォルトで有効になっています。これは、OpenSSLのバージョンがこのバージョン以降であり、SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS暗号を制限したり、TLS 1.0を無効にする必要はありません。
私の理解では、CBCモードのブロック暗号を使用したTLS <1.1はBEASTに対して脆弱です。繰り返しになりますが、私の理解では、TLS 1.1以上を使用するか、ストリーム暗号を使用するしか選択肢がありません。
または、もちろん、SSHのようにBEASTの影響を受けない別のプロトコルを使用することもできます:)