要約

  • STARTTLS 後も TCP 接続は続くが、NNTP のアプリケーション状態は原則として最初の挨拶直後へ戻る。
  • サーバーは平文時に知ったグループと記事位置を、クライアントは古い機能一覧を捨て、保護後に再取得する。
  • TLS は一つの区間を守るだけで、NNTP の認証、記事の著者性、複数中継にまたがる来歴を自動的には保証しない。

境界の直前で価値を失う情報

RFC 977 が描いた初期 NNTP は、接続、サーバーの挨拶、コマンド、三桁応答という会話だった。クライアントは会話の途中でグループを選び、現在の記事位置を持つ。状態があるから効率よく読める一方、後に TLS を挿入すると難問が生まれる。平文で作った状態を、そのまま暗号化後の判断材料にしてよいのか。

RFC 4642 の答えは否だった。サーバーが 382 を返すと、改行の次のオクテットから TLS 交渉が始まる。STARTTLS はパイプライン化できない。失敗すれば、両者は不確定な解析状態を避けるため接続を閉じるべきだとされた。

成功時はさらに独特だ。新しい TCP 接続を作るのではない。ところが NNTP は、ほぼ最初の挨拶直後へ戻る。挨拶は再送されず、クライアントが次のコマンドを出す。同じ管の中で、会話の根拠だけが入れ替わる。

グループ選択を持ち越さない

サーバーは、TLS 交渉そのものから得た情報を除き、交渉前にクライアントから得た知識を破棄しなければならない。仕様は現在のニュースグループと記事番号を例示する。クライアントも、交渉前にサーバーから得た機能一覧に依存してはならない。

理由は時間の非対称性にある。TLS は交渉後の通信を保護できても、交渉前の発言を遡って真正にできない。平文で改変されたグループ選択が保護後も残れば、暗号化された操作が攻撃者の入力を実行する。古い機能一覧を信じれば、削除された安全機能や偽の選択肢が新しい段階を支配する。

RFC 3977 は CAPABILITIES を、その時点のサーバー能力を知るコマンドと定義する。状態変化によって一覧は同一セッション中でも変わり得る。したがって一覧は設備台帳ではなく、時点付きの観測である。

例外もある。先に MODE READER を実行していた場合、その効果は TLS 後も逆転しない。全面消去ではなく、機密な前提を信頼境界の外へ留めつつ、プロトコルが定義した役割変化だけを保存する設計だった。

保護後に機能を聞き直す

TLS が成立したら、クライアントは CAPABILITIES を再発行し、必要な状態を再交渉する。新しい一覧から STARTTLS は消える。すでに安全層があるからだ。証明書に依存する SASL 機構などが新たに現れることもある。

ここには二種類の記憶がある。現在のセッションでは、平文一覧を忘れる。別セッションとの比較では、以前 TLS を提供したサーバーが突然提供しなくなった事実を覚えておくと、ダウングレードを部分的に検出できる。忘却と記憶は矛盾せず、守る対象が違う。

証明書は NNTP の認可ではない

クライアント証明書を TLS で提示しても、NNTP サーバーはアプリケーション上の未認証状態に残る。RFC 4643 の例では、TLS 後に機能一覧を取り直し、それから AUTHINFO SASL を実行する。EXTERNAL が使える場合、証明書由来の身元を利用できるが、認証の成立は別の NNTP 応答で確定する。

これは形式上の重複ではない。証明書が名前と鍵を結び付けても、その身元にどのニュースグループを読ませ、投稿させるかはサービス側の決定である。STARTTLS を実装したサーバーに AUTHINFO や EXTERNAL の実装義務はない。

一つの安全区間と記事の来歴

Netnews の記事は複数のサーバーを渡り得る。RFC 4642 は、TLS が守るのは一組のクライアントとサーバーの間だけだと明記する。一つの区間を暗号化しても、経路全体が非公開になったとは言えない。

転送元を認証できても、その転送元が記事を受け取った経緯や著者の身元までは証明しない。接続相手、利用権限、記事内容、上流の来歴は別々の証拠である。IANA の NNTP パラメータ にある STARTTLS 登録も、標準機能の存在を示すのであって、特定経路の安全性を保証するものではない。

NNTP STARTTLS の核心は、接続の継続と信頼の継続を分けた点にある。安全な段階は、外側で得た断定を相続しない。能力を聞き直し、状態を作り直し、認証を別に行い、一つの区間以上の権威を主張しない。暗号化は忘却の後に初めて意味を持った。

出典