要約

  • XMPPではTLSとSASLの成功後、通常の</stream>を送らず、TCP接続も閉じずに、現在のXMLストリームだけを置き換えた。
  • 新しいヘッダー、ストリームID、機能一覧は変化後の状態を表した。TCP接続、暗号化、相手の検証、SASL認証、リソース束縛、スタンザの受理は別々の証拠だった。

「つながっている」だけでは現在地が分からない

クライアントがXMPPサーバーへストリームを開き、サーバーがSTARTTLSを提示する。クライアントが要求し、TLSハンドシェイクが成功する。ここで同じXMLストリームを暗号化済みとして続けることはしない。

クライアントは、暗号化された既存TCP接続の上に新しい初期ストリームヘッダーを送る。旧ストリームを閉じるタグは先に送らない。サーバーは新しいIDを生成して応答し、その状態で有効な機能を改めて提示する。

SASLの<success/>でも似た境界を越える。認証交換が成功したという知らせは、その交換を収めていたストリームを完成形にするのではなく、役目を終えさせる。クライアントは同じTCP上でまた新しいストリームを開き、サーバーは認証後の機能を返す。

つまり一つのソケットが、TLS前、TLS後、SASL後という複数の「現在」を運ぶ。接続の有無だけを見ても、どの段階の主張が有効なのかは判定できない。

XMLストリームには輸送路とは別の寿命があった

RFC 6120では、TCPとXMLストリームは同じものではない。TCPは双方向だが、厳密には一つのXMPPストリームは一方向であり、当事者は両方向のストリームを組み合わせて対話する。

再開始が必要な機能の交渉に成功すると、双方は以前のストリームが置き換わったと考える。通常の閉じ方をせず、TCPも切断しない。状態が変わった既存接続を再利用し、発信側が新しいヘッダーを、受信側が新しいストリームIDを出す。

これはTCP再接続ではない。再接続なら新しい輸送関連を作り、経路やポート、混雑状態も改めて扱う。XMPPが保存したかったのはその下層の連続性であり、保存してはいけなかったのが上層の交渉文脈だった。

また、アプリケーションメッセージの再送や到達確認でもない。ストリームを開き直しても、過去のスタンザが届いたこと、再送すべきこと、相手のアプリが処理したことは証明されない。

機能一覧は相手と段階に応じた問いだった

サーバーが返すstream featuresには、必須の交渉と任意の交渉が含まれる。必須項目が残っていれば準備は終わっておらず、通常のスタンザ送信へ進めない。空の一覧、または任意項目だけの一覧になって初めて、その段階の交渉完了を示す。

提示順には依存関係がある。RFC 6120はTCP、TLS、SASL、XMPPという層の順を示す。TLSの有無でサーバーが提示するSASL機構が変わり得る。クライアント向けのリソース束縛はSASL認証後でなければ提示されない。

再開始後に機能を送り直すのは、製品の能力一覧を二度見せるためではない。新しい保護・認証状態で、その相手が今交渉できるものを答え直すためだ。前の一覧をコピーすれば、条件付きの許可を恒久能力に変えてしまう。

見えなかった機能についても断定はできない。まだ提示する段階でない、すでに役目を終えた、あるいは方針で出さない可能性がある。RFC 7590は、攻撃者がSTARTTLSの提示やrequiredを取り除けることにも触れる。観測した一覧はその経路の証拠であり、サーバーの全知的な目録ではない。

TLSは過去の発言をさかのぼって保護しなかった

TLSが成功すると、双方はTLS有効化前にTCPより上の層で安全でない形で得た情報を捨てなければならない。RFC 6120は、相手のfrom、旧ストリームID、旧機能一覧などを例に挙げる。

暗号化前に中間者が書き換えた主張を、暗号化後もそのまま信用すれば、保護された区間が過去の未保護データに権威を貸してしまう。新しいヘッダーと機能は儀礼ではない。新しい条件の下で、主張を受け取り直すための境界である。

ただし、TLS成功を相手の本人確認と同一視することもできない。暗号化、証明書などによる検証、対象名、検証結果、受入方針はそれぞれ記録が必要だ。RFC 7590はクライアントによるサーバー認証とサーバーによるクライアント認証を求め、サーバー間でも認証を強く推奨する一方、暗号化されても認証されない接続を弱い別ケースとして扱う。

post-TLSストリームが存在することは遷移の事実であって、相手の身元に関する完全な証明書ではない。

SASLの成功後にも未完了の仕事が残った

RFC 4422のSASLは、接続指向プロトコルが交換可能な認証機構を利用するための枠組みである。認証した主体、代理で行動するための認可主体、交換結果、機構によっては得られるデータ保護層を区別する。すべての機構が同じ保護をもたらすわけではない。

XMPPはSASL交換をXMLで運び、成功後にストリームを開き直す。そこで初めてサーバーは認証済みの相手に向けた機能を提示できる。しかし<success/>は、どんな宛先にも送れるという包括許可ではない。

クライアントにはリソース束縛が残る。認証したアカウントにresourcepartを結び付け、同じアカウントの複数接続を区別する工程だ。サーバーはこの機能をpost-SASLストリームで提示する。

束縛前にクライアントがサーバーまたは自分のアカウント以外へスタンザを送れば、サーバーは処理せず、not-authorizedでストリームを閉じなければならない。TCPもTLSもSASLも成功していてなお、「通常送信可能」には達していない。

束縛の後は、もう開き直してはいけなかった

RFC 6120は、リソース束縛後のストリーム再開始を明示的に禁じる。この一文が、再開始の意味をよく示している。XMPPは成功のたびに反射的にリセットしたのではない。

TLSとSASLは、旧情報を解釈する安全・身元条件を変える。束縛は、すでに認証後の新ストリーム内でアドレスを完成させる。そこでさらに文脈を捨てる必要はない。

実装は「成功ならrestart」という一行では足りない。TLS後にしないのも誤り、SASL後にしないのも誤り、束縛後にするのも誤りになり得る。それぞれの境界が何を無効化するかを知る状態機械が必要だ。

証拠の意味も同じである。新しいストリームIDは世代を関連付ける値であって利用者IDではない。resourcepartは接続中の資源を区別するが、恒久認可や配送結果ではない。ローカルサーバーの受理と遠隔アプリの効果も別である。

2004年の手順を2011年が一つの原理にした

2004年10月のRFC 3920は、TLS成功後とSASL成功後に新しいストリームを開始する手順をすでに定めていた。TCP、TLS、SASL、XMPPの順も示し、成功時点で旧ストリームを閉じたものとみなした。

2011年のRFC 6120は旧文書を置き換え、既存TCPの再利用、旧ストリームの置換、新しいID、更新済み機能という一般則を明瞭にした。restartを後から発明したのではなく、複数の手順を段階交渉の原理として整理したのである。

2015年のRFC 7590は、変化した脅威に合わせてTLS運用を強化した。正しい順序でヘッダーを交換することと、十分な暗号・検証方針を採ることは別だという注意も残る。

この歴史が示すのは、効率と信頼を同じ寿命にする必要はないということだ。輸送路は使える限り残せる。だが、そこで語られた事実の根拠が変わったなら、古い文脈には退場してもらうべきだった。

参照資料