すべてのHTTPSリクエストとレスポンスにランダムパディングを含める必要がありますか？
次の論文によると、 HTTPSトラフィックを復号化することが可能 AJAX呼び出しを検査し、サイズパラメータを暗号化Oracleとして使用することにより、.
すべてのHTTPS GETまたはPOSTとともに可変長ペイロードを送信する必要がありますか？この攻撃から身を守るにはそれで十分ですか？
HTTPS応答にも可変長文字列を追加する必要がありますか？
ランダムな長さのデータのランダムな付属物はどのくらいの大きさにすべきですか？
外部からは、交換されたデータのlength、つまり要求の全長と応答の全長（対称暗号ブロックサイズの倍数に丸められます。 AESが使用されている場合は16バイトですが、RC4では丸められません）。情報の漏えいを防ぐために、すべての要求とすべての応答は、まったく同じサイズでなければなりません。したがって、パディングは可変サイズにする必要がありますパディングされたデータの長さに依存します。ランダムな長さのパディングを追加するが、パディングされた要求または応答のサイズに依存しない確率分布を使用する場合、その要求が定期的に実行される場合、元の要求の長さを統計的に再構築できます。
パディングバイトをランダムにする必要はありません。 「外側から」は長さだけが見えます。定数のバイト値を使用できます（例：カスタムHTTPヘッダーX-Padding: ZZZZZZZZZ、コンテンツとして、適切な長さの'Z'のシーケンス）。ランダムデータの使用couldは実際にタイミングを通じて追加情報をリークします（ランダムジェネレーターが非常に高速でない場合、攻撃者はクライアントまたはサーバーの反応時間を観察してパディングのサイズを推測し、間接的に真を取得する可能性がありますリクエストまたはレスポンスの長さ）。
常に固定サイズをターゲットとすることは、ネットワーク帯域幅を浪費することになります。これは、すべてのリクエストが可能な最大のリクエストのサイズを持ち、すべてのレスポンスが可能な最大のレスポンスのサイズになるためです。 @Paŭloは、指定された値の次の倍数（たとえば、500バイトの倍数である次の長さまで）までパディングすることを推奨しています。これは、常に同じ長さまでパディングするよりも少しリークしますが、リークしません。多く;また、ネットワークリソースの浪費を防ぎます。