要約

  • 206 応答の末尾CRLFの直後から、以後のコマンドと応答は双方向で圧縮され、同じ接続内で元に戻す命令はなかった。
  • 圧縮開始後は STARTTLS、AUTHINFO、MODE READER が閉ざされるため、TLS、認証、圧縮を併用する順序はその並びに固定された。
  • 送信時の圧縮はSASLやTLSより前に動くので、辞書の共有範囲、出力長、flush、破損時の切断がセキュリティ制御になった。

成功応答が選択肢を減らす

通常、成功は次にできることを増やす。しかし COMPRESS の成功は逆だった。帯域を節約する層が有効になると、その接続では後から保護層を差し込んだり、資格情報を渡したりできなくなる。

これは圧縮が単発の変換ではなく、過去の入力を覚えるストリームだからである。両端が次のバイトに同じ変換を施すという前提を共有する。片側だけが生のNNTPに戻れば、コマンド境界そのものが壊れる。

RFC 8054 は停止方法を QUIT と新しい接続に限定した。圧縮を最初に選んだクライアントが後悔しても、その接続を組み替えるのではなく、最初からやり直す。

境界はCRLFの次に置かれた

サーバーの 206 Compression active はまだ非圧縮で届く。成功行を終えるCRLFの直後、圧縮層が両方向で有効になる。最後の平文応答と最初の圧縮バイトの境界が一意に決まる。

そのため COMPRESS はパイプライン化できない。クライアントは結果を見る前に次のコマンドを送ってはならない。拒否なら次の行は従来どおり、成功なら圧縮ストリームで送るからだ。

構文不正、未対応アルゴリズム、資源不足は別々の拒否になる。これらは状態を変えない。206 だけが接続の表現規則を切り替える。

個別コマンドではなく接続全体を圧縮する

以前の非標準方式には、サーバーからの特定応答だけを圧縮するものがあった。RFC 8054は個別の圧縮版コマンドを増やさず、以後すべてのNNTPコマンドと応答の下に損失のない層を置いた。

繰り返されるクライアント命令も、大きな一覧、記事ヘッダー、本文も同じ仕組みを通る。RFCの性能節は、大きな複数行応答がよく縮む一方、短い応答や符号化済み添付は効果が小さい場合を説明する。これは情報提供用の観察であり、現在の製品に対する普遍的な比率ではない。

RFC 1951 のDEFLATEが標準アルゴリズムとなり、拡張の必須実装になった。各送信側は自分の方向の圧縮強度を選び、受信側はそれに適応する。層は双方向でも、調整値まで対称とは限らない。

一度始めると能力表から扉が消える

圧縮中のサーバーは COMPRESS と STARTTLS を能力表に載せない。二重圧縮や、TLS側の圧縮を含み得る後続の安全層は許されず、有効な命令でも 502 になる。MODE READER も後から実行できない。

RFC 3977 の能力表は接続状態の観測であり、途中で変わり得る。特に圧縮は暗号化を弱める可能性があるため、以前のセッションで得た広告を現在の根拠にしてはならない。

能力が消えたことは実装の気まぐれではない。いま到達できない状態遷移を正直に表す。クライアントは古い一覧より、圧縮がすでに有効だという現在の事実を優先しなければならない。

資格情報を後から通せない理由

圧縮は同じ文字列を短く表す。暗号化が内容を隠しても、圧縮後の長さまで必ず隠すとは限らない。攻撃者が一部の入力を変え、暗号文の長さを観察できれば、既知文字列と秘密の一致が手掛かりになる。RFC 8054はCRIMEとBREACHをこの危険の例に挙げる。

そこで、アプリケーション圧縮後の認証は禁止された。未認証の相手に対し、サーバーは AUTHINFO を隠すか、利用可能な引数を示さない。クライアントが有効な認証命令を送っても 502 で拒む。

RFC 4643 が定義する認証は、サーバーがアカウント主体を受け入れる行為である。圧縮は主体を証明しない。順序制約は、資格情報を既存の圧縮辞書へ入れないための境界だった。

三つを得る唯一の組み立て順

TLS、認証、アプリケーション圧縮を同じ接続で使うなら、RFC 8054は STARTTLS、AUTHINFO、COMPRESS の順を求める。RFC 4642 のTLS遷移でリンクを保護し、次に認証を完了し、最後に圧縮の長さリスクを選ぶ。

三つの権限は別々である。TLSは通信路を保護してもアカウント権限を作らない。認証は圧縮率を保証しない。圧縮は暗号化も認可もしない。必要な順序があるからといって、役割が混ざるわけではない。

送信処理もこの分離を映す。まず COMPRESS、次にSASL安全層、最後にTLSを適用する。受信時は逆順で元のNNTPを得る。圧縮は反復を見つけるため暗号化前のデータを見る。

辞書を共有する範囲が漏えい面を決める

公開記事と機密記事を同じ圧縮履歴に入れると、既知の公開文字列が秘密を測る足場になり得る。RFC 8054は安全層がある場合に両者を一緒に圧縮しないよう求め、異なる機密記事同士も可能なら辞書を分けるよう勧める。

DEFLATE辞書の消去は一つの対策である。これは接続の暗号を変えるのではなく、どの過去データが次の出力長へ影響できるかを狭める。辞書境界は、データ分類と同じくらい運用上の信頼境界になる。

仕様は暗号化と圧縮の併用を一律禁止しない。その代わり、安全層の下で自動的に有効化せず、利用者がリスクを理解して選ぶことを求めた。

圧縮状態が壊れたら接続を閉じる

送信側は圧縮へ渡した全データを出力に含め、相手が完全に展開できるよう適切にflushする。圧縮しにくい大きな添付の前後で強度を変えることはできるが、対話データを届かないまま保持してはならない。

受信した圧縮データが不正または破損していれば、接続を直ちに閉じる。次に見える改行から再開しない。辞書履歴が食い違った後の文字列は、偶然NNTPらしく見えても信頼できないからだ。

新しい接続は圧縮を停止する方法であると同時に、破損後に共有状態を作り直す方法でもある。回復の権威は古い流の推測ではなく、明確な新しい始点に置かれた。

最後に来る層が順序を固定した

IANAのNNTPパラメータ登録簿 は COMPRESS とDEFLATEを登録する。共通名と参照仕様を与えるが、導入状況、性能、安全な設定を保証しない。

接続全体の圧縮は、個々の命令を複雑にせず双方向の冗長性を減らした。その代わり、成功は将来の選択を減らし、秘密の扱いを順序へ結び付けた。

圧縮を最後にするという規則は、速度より安全を常に選べという標語ではない。保護と認証を後付けできない変換である以上、先に済ませるべき決定を明示したのである。同じ三つの機能でも、正しい順序だけが同じ接続に三つの意味を残した。

出典