要約

  • TLS 1.3は、内容、非ゼロの内部ContentType、末尾のゼロパディングをまとめて保護する。送信側が長さを選び、受信側は検証後にゼロを取り除いて内容だけを上位へ渡す。パディングは表現であって命令ではない。
  • 受動観測で証明できるのは暗号文長、方向、時刻である。内容、種別、パディング、AEADオーバーヘッドを直接分離できないため、大きいレコードだけで大きいアプリケーションメッセージを証明できない。
  • パディングは長さ指紋を粗くし、カバートラフィックを作れる。ただし時刻、個数、応答、分割、処理時間は残る。結論には端点の前後長、版管理された方針、交渉上限、拒否試験が必要だ。

正しい差分が誤った出来事になった

同じ接続の二つの外向きレコードには512バイトの差があった。大きい方の時刻が機微な業務操作と重なったため、差分はペイロードとして数えられ、操作主体の証拠とされた。

端点の記録は別の経路を示した。コールバックが各Application Dataを次のブロック境界までゼロで補い、無通信時には内容長ゼロのレコードも生成していた。追加分は帯域を使う実在のバイトだが、すべてが利用者データではない。

誤りはキャプチャ品質ではなく、権限範囲にあった。ネットワークの観測値に、復号後の意味を決める権限を与えてしまった。

TLSInnerPlaintextの境界

TLSInnerPlaintextは内容、その直後の非ゼロContentType、末尾の任意個のゼロで構成される。全体が暗号化・認証され、外側の型は互換性のためApplication Dataに見える。

AEAD復号と検証に成功すると、受信実装は返された平文の範囲内だけを末尾から走査する。ゼロを飛ばし、最初の非ゼロ値を内部型とする。その前が内容である。非ゼロ値がなければunexpected_messageで接続を終了しなければならない。

意味の境界を確定できるのはこの端点処理である。上位アプリケーションに渡るのはパディング除去後の内容だけだ。認証されたゼロであっても、API呼出し、資格情報、権限にはならない。

カバートラフィックにも文法がある

Application Dataは内容をゼロ長にできる。実処理がない時間にも妥当そうな長さの保護レコードを送れるため、「通信があった」ことから「利用者操作があった」ことへ直行できなくなる。

HandshakeとAlertには同じ許可がない。空メッセージをゼロで膨らませても有効な状態遷移にはならず、受信側は拒否する。占有したバイト数がプロトコル事実を作るわけではない。

また、カバーが完全な秘匿を保証するわけでもない。応答、処理遅延、バースト、終了時刻から実処理を区別できることがある。長さ信号は鈍るが、他の信号は残る。

ゼロも上限を消費する

TLSの最大値とrecord_size_limitは、内容だけでなく内部型とパディングを含む完全な平文に適用される。小さい上限を受け取った送信側は、その範囲を超える保護レコードを作れない。

したがって「1024バイト加える」という方針は結果を保証しない。現在の内容が既に空間を使い、実装は追加量を切り詰めたり、先に分割を変えたりする。OpenSSLの実装も最大平文長を超えない値に制限する。

同じアプリケーション内容でも、上限と分割により一個、複数個、希望幅未満のレコードになり得る。最終長だけから逆算するには状態が足りない。

機構があっても方針が動いているとは限らない

現行TLS 1.3仕様は符号化と検証を定めるが、普遍的なブロック幅やカバー頻度は定めない。アプリケーションが機微なメッセージ境界を知る場合は上位層での調整が適することもある。暗号化されたHandshakeとAlertのパディングはTLS層の仕事である。

OpenSSLの既定値はパディングなしである。ブロック幅または書込みごとのコールバックを設定でき、Application DataとHandshake/Alertを別幅にできる。コールバック設定はkernel TLSと両立しない場合がある。

GnuTLSには送信単位の追加長と長さ隠蔽の可否を扱うAPIがある。APIやIANA登録は能力の証拠にすぎず、対象プロセスで有効だったことや実際の追加長を証明しない。

ライブラリを一定時間にしても処理全体は一定にならない

パディング除去の所要時間が長さに依存する可能性がある。GnuTLSのGNUTLS_SAFE_PADDING_CHECKはその漏えいを抑えるための選択肢で、性能コストを伴う。

その後、アプリケーションは実内容に応じて解析、割当て、照会、応答を行う。TLS内の走査が一定時間でも、上位の動作が一定時間とは限らない。

仕様が交通解析への完全防御を約束しない理由はここにある。より強い保証には上位プロトコルとの協調、追加トラフィック、遅延が要る。「パディング有効」は一機能の状態であり、プライバシー成果そのものではない。

組合せごとに層を選び直す

EAP-TLS 1.3は証明書サイズの漏えいを減らすためレコードパディングを推奨する。ECHは内部ClientHelloを独自に丸め、機微な長さを持つ後続の暗号化HandshakeにもTLSレコードパディングが必要になり得るとする。どちらも守る対象を先に定めている。

HTTP/3はアプリケーションフレーム、予約フレーム、トランスポートのパディングを区別する。QUICはTLSハンドシェイクを利用するが、通常のTLSレコードをそのまま運ばない。TLSコールバックの設定をQUICパケットの事実へ転記してはならない。

integrity-onlyのTLS 1.3暗号スイートも境界を示す。パディングを含めて完全性を保護できても、暗号化がなければ平文長を隠せない。ゼロの存在だけでは秘匿にならない。

観測者が言えること

受動キャプチャは端点、方向、時刻、暗号文長、パケット化、再送を記録できる。内部型、内容長、追加ゼロ、業務上の意味は直接見えない。

安全な記述は「端点が時刻TにNオクテットの保護レコードを送った」である。端点ログがあれば、「Cオクテットの内容に方針Pの版VでZを加え、上限Lの下で内部長I、暗号文長Nになった」と拡張できる。

この接合がなければ、分布は仮説を支えるにとどまる。人の操作やオブジェクトサイズを確定する根拠にはならない。

後日の検証に耐える台帳

接続、方向、シーケンス、TLS版、保護方式、内部型、追加前内容長、要求・適用パディング、内部・暗号文長、交渉上限、分割、ライブラリ版、kernel TLS、方針版を保存する。

帯域、遅延、CPU、長さバケット、応答相関、カバー比率も同じ変更単位で測る。Application DataとHandshake/Alertを分ける。

全ゼロ平文、空Handshake、空Alert、過大要求、上限超過の拒否を試験し、実際のアラートを残す。方針を無効化した後はコールバック動作と特徴的な長さ分布が消えたことを確認する。

最重要値はネットワークから見えない追加前の内容長である。これがなければ、観測長はネットワーク証拠であってアプリケーション権限ではない。

出典