[13] HTTP/2 のいくつかのフレームでは、 payload に実際の長さを隠すための詰め物paddingを挿入することができます。

仕様書

構文

[3] DATA フレーム >>2 や HEADERS フレーム >>14 や PUSH_PROMISE フレーム >>15 には、 詰めPadding欄があります。 これはメッセージの長さを隠すためのセキュリティー機能です >>2。

[4] 送信者は、詰めをすべて 0 のオクテットにしなければなりません >>2。

[5] 詰め長欄の長さより、詰め欄の最大長は、255バイトです。

[9] DATA フレーム >>2 や HEADERS フレーム >>14 には、詰め長Pad Length欄があります。 これは詰めの長さをバイト単位で8ビットで表したものです >>2, >>14, >>15。

[6] 詰め長欄 (と詰め欄) は、 PADDED フラグが設定されている場合のみ存在します >>2, >>14, >>15。

[7] 値は0でも構いません。値が実際の詰めの長さを超えることは禁止されていませんが、 当然正しく処理できませんし、payload の長さを超えるなら接続エラーとなります。

[12] DATA フレームや HEADERS フレームの PADDED (0x8 = 第3ビット) フラグは、 設定されていれば詰め長と詰めの欄が含まれることを表します。 >>2, >>14, >>15

文脈

[38] 詰めは、フレームの内容の実際の大きさを隠し、 BREACH攻撃などを難しくするために使うことができます。 >>36

[39] しかしこれは TLS/1.2 などのような一般目的の詰めの代替を意図したものではありません。 >>36

[40] 適切に扱うためには、詰めを追加する対象のデータの性質を知っている必要があります。 また詰めによる防御効果は見かけより少なく、攻撃者が観測しなければならないフレームの数を多少増やす程度かもしれません。 適切に実装されなければ、詰めの方法は簡単にわかってしまうかもしれません。 >>36

[41] 圧縮を使った攻撃を防ぐには、詰めを使うのではなく、 圧縮を無効にしたり制限したりする方が適切かもしれません >>36。

処理

[8] 詰めと payload の長さに関する問題は、エラーとなります。

DATA フレームの処理の項を参照。

[11] 受信者は、詰めに 0 以外があれば接続エラー PROTOCOL_ERROR としても構いません。 >>2

[10] 相互運用性の問題が生じるかもしれませんし、実装により扱いが異なるのは fingerprinting vector かもしれません。

[42] 中間器は DATA フレームの詰めを残すべきですが、 HEADERS や PUSH_PROMISE では削っても構いません。 >>36

[1] ヘッダーブロックは再符号化が必要なので、 payload の状態をそのまま転送する必要もないからでしょう。

[16] Implement padding PUSH_PROMISE and HEADERS frames. (issue 661743003 by b...@chromium.org) - Google Groups ( 版) https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/147G5N9izTw