TLSのパディングによるRC4バイアス保護
TLSでのRC4の脆弱性に関する私の以前の質問 に対する答えについて、Thomas Porninは素晴らしい答えを出しました。
何度も提案されてきたRC4を「修正」する1つの方法は、出力の最初の256（または512または1536など）バイトをドロップすることです。これは、これらが最もバイアスされているためです（スライドのグラフィックは、明らかに）。しかし、これはRC4-as-we-know-itと互換性がありません。
これと、興味深い提案をする HNに関するコメント に興味があるので、ブラウザ（またはブラウザプラグイン）がHTTPリクエストをパディングでき、最初の256バイト（または512など） ）は単なる役に立たないヘッダーです。例えば.
GET / HTTP/1.1
X-Padding-Header: <256 bytes of random text>
Accept: */*
...
私の知る限り、不明なヘッダーは無視されます（？）。これにより、要求の最初のバイトが役に立たない（それらを推測しても意味がありません）とランダムになります。
これは良いよりも害を及ぼすかもしれない愚かな回避策ですか？または、ブラウザがそれを修正しようとしている場合、TLS 1.2にアップグレードすることもできますか？
（もちろん、URL自体に機密情報が含まれ、十分に長い場合、リクエストのヘッダーの前に存在するため、この「保護」はこれには役立ちませんが、Cookieを保護するには十分でしょうか？）
@ D.W。指摘すると、これはcookieを保護するために機能します。 path自体はヘッダーの前にあり、予測可能な場所に機密データが含まれている場合、危険にさらされる可能性があります（これは現在では一般的なケースではありませんが、セッション管理用のURL書き換えが一般的でした）。
バリアントは次のようになります。
GET / HTTP/1.1
X-Header-Padding1: <X random padding bytes>
Accept: */*
Cookie: ...
...
X-Header-Padding2: <Y random padding bytes>
XとYをランダムに選択しますが、X+Yは固定されています。ストリーム内のcookieの配置は、リクエスト間で変化します。これは、攻撃者が検出できない方法です（ヘッダーの全長が一定であるため）。リクエストの最初の256バイトを単にドロップするほど満足いくものではありませんが、これはバイアスベースの攻撃の労力を数百万ではなく数十億のリクエストに戻すのに十分であり、256未満の追加で実行できます。リクエストあたりのバイト数（X+Y = 32はそれを行う必要があります）。
これは、私が知っているすべての攻撃に対して安全です。
セキュリティの観点からは、最初の256バイトまたは512バイトを削除することとはまったく同じではありません。あなたの提案では、攻撃者は既知のプレーンテキスト（たとえば、GET行とX-Padding-Headerから）を持っていますが、最初の256バイトをドロップすると、攻撃者はそれらの位置で既知のプレーンテキストを取得しません。理論的には、RC4からの出力の最初の256バイトの一部についての知識が攻撃者にキーの回復を許可した場合、スキームは不十分になります。しかし、私はそのフォームのRC4に対する攻撃を知りません。実際には、RC4に対するすべての既知の攻撃は、RC4からの出力の最初のバイトの1つまたは2つがわずかにバイアスされているため、プレーンテキストを希望どおりに非表示にしないと述べていますが、このバイアスは攻撃者がRC4キーを推測できるようにします。したがって、セキュリティの観点から見ると、実際には、RC4出力の最初の256バイトをドロップするのとほぼ同じくらいのスキームになります。
ただし...パフォーマンスの観点からは、SSL経由で送信されたeveryリクエストに256バイトが追加されました。これはパフォーマンスにとって非常に悪いことです。このパフォーマンスの問題は、この提案を無効にするのに十分な可能性があります。おそらく、展開の実行可能な候補ではありません。
ブラウザーがそれを修正したい場合は、単にTLS 1.2およびより安全な暗号スイートに更新する方がはるかに良いでしょう。