要約

  • FEATはFTP拡張を一つずつ試す代わりに、文書化された対応機能を一覧として問い合わせる仕組みだった。
  • 適合する成功応答は対応拡張を網羅したが、500や502は拡張の不在を意味しなかった。FEAT以前の実装が古い拡張だけを持つ場合があったからだ。
  • OPTSの成功は後続命令の設定を受け入れた証拠であり、利用者の権限、命令の完了、データ転送の結果まで証明するものではなかった。

問い合わせが操作になってしまう問題

RFC 959のFTPは、後から機能を足せる余地を持っていた。その余地は実装差も生んだ。新しい拡張を知っているクライアントが接続しても、相手のサーバーが同じ拡張を採用しているとは限らない。

相手が命令を理解するかどうかは、命令を送れば分かるかもしれない。だが、その確認法は情報取得と状態変更を混同する。RFC 2389は、候補となる命令を順番に試すことが通信を増やすだけでなく、意図しない作用を起こし得ると説明した。読み取りの質問に、実行の副作用が付いていたのである。

FEATは引数を持たない短い問い合わせとして、この混同を解いた。応答するサーバーは、自分が実装する拡張を構造化した一覧にする。クライアントは自分が理解するものだけを選べる。共通仕様が決めるのは一覧の外枠であり、各拡張の意味やパラメーターは各文書に残った。

ここで得られたのは中央の許可ではない。サーバーが記述し、クライアントがローカルに判断し、その後の命令が改めて実行条件を問われるという順序である。

一文字分の空白が守った境界

機能がある場合の応答は、211-で始まる複数行形式を取る。各機能行の先頭には必ず一つの空白が置かれ、最後に211 Endが来る。空白は見た目を整えるためではない。機能行が終了行と誤認されないための構文だった。

先頭行の説明は自由だが、以後の機能行には規則がある。機能ラベルは命令名と同じこともあるが、必須ではない。後ろに続くパラメーターの意味は、その機能を定めた文書が持つ。並び順に意味はなく、同じサーバーが毎回同じ順序を返す必要もない。

未知のラベルもエラーではなかった。将来の拡張を古いクライアントが見たとき、理解できない部分を無視して共通部分を使い続けられる。新情報の存在を、会話全体の破損と扱わない設計である。

一覧にはFEAT自身を載せない。500または502以外の応答が、その対応をすでに示している。OPTSも、FEAT実装時に必須だったため載せない。表示する内容を増やすより、何がすでに証明されたかを区別した。

肯定の一覧は閉じるが、取得失敗は不在を閉じない

RFC 2389は、成功時と失敗時に対称な推論を許さなかった。

FEATを実装するサーバーは、RFC 959とRFC 2389より後の、正しく文書化された対応拡張をすべて一覧に含めなければならない。したがって適合する成功一覧では、載っていない拡張を非対応と判断できる。一覧はその範囲で完備している。

しかしFEATに500または502が返っても、サーバーが拡張を一切持たないとは言えない。機能一覧より前に普及した拡張があり、古いサーバーはその命令を理解してもFEATを知らない場合がある。互換性を求めるクライアントは、古い拡張だけを個別に試す余地を残された。

FEATを理解しながら追加機能がないサーバーには、一行の211応答が推奨された。それでも500や502が許されたのは、クライアントから見ると「一覧機能を知らない」と「一覧は空」が実質的に区別できない場合があるためだ。

正しく得た一覧の欠落には意味がある。そもそも一覧を得られなかったという欠落には、同じ意味がない。この非対称性は不便ではなく、配備の歴史を偽らないための条件だった。

OPTSは未来の命令を整える

拡張機能は単純な有無だけではない。OPTSは、対象命令と希望する選択肢を伝え、その後の命令の振る舞いを設定する共通の器だった。具体的な書式と効果は対象命令の文書が定義する。

200は対象と選択肢が認識され適切だという返事である。501は状態が変わらなければ再試行しても失敗する恒久的な問題、451は後に解消し得る一時的なサーバー条件を示す。どれも対象命令の実行完了ではない。

RFC 3659のMLSTでは、この段階差が見える。FEATのMLST行は利用可能なファイル属性を並べ、既定で返すものにアスタリスクを付ける。OPTS MLSTを送ると、後のMLSTとMLSDが返す属性集合を変えられる。既定外の属性には生成コストが高いものもあり、必要なしに求めないよう注意された。

対応していること、既定で選ばれていること、クライアントが要求したこと、個別のファイルに適用できること、実際の応答に含まれたことは別である。OPTSはこの違いを消すのではなく、観測可能にした。

TLSを広告しても、TLSはまだ始まっていない

RFC 4217はFTPをTLSで保護する際にFEATを利用した。対応サーバーはAUTH TLS、PBSZ、PROTを広告する。だが、その行は利用可能な交渉経路を示すだけで、保護済み接続を作らない。

クライアントはAUTH TLSを送り、サーバーが234で受け入れ、TLSハンドシェイクを終え、保護パラメーターを設定し、証明書の名前と信頼を検査し、必要ならFTP利用者の認証も終えなければならない。機能表は、後続のどの判断も代行できない。

RFC 7151のHOSTも同じ構造を持つ。仮想ホスト対応はHOSTの広告で分かるが、ホスト選択は認証環境を変え得る。指定名と証明書の識別名の一致も別に検査される。入口があること、入口を選ぶこと、正しい相手を信頼することは一つではない。

登録表が守るのは名前の一意性

拡張が増えた後、RFC 5797はIANAのFTP Commands and Extensions登録表を設けた。同じ命令名や機能名が別の意味に使われる衝突を減らすためである。命令、FEATコード、説明、種類、適合上の位置付け、参照文書が記録された。過去の名前も再利用防止のため残された。

同RFCは、登録が拡張の「承認」を意味しないと明記した。永続的で公開された仕様があるか、一般に入手可能なクライアントとサーバーに実装されていれば、登録の根拠になり得る。小文字の疑似コードは名前の予約であり、実際のFEAT応答に出すものではない。

登録表は名称と定義の対応を守る。個々のサーバーの対応はサーバーが示す。利用可否は認証と方針が決める。命令応答とデータ接続が実行を示す。最終ファイルの状態が意図した成果を示す。この階層を一枚の表に圧縮すれば、調整用の台帳が持たない権限まで持つように見えてしまう。

限定的な開示と、より危険な探索

RFC 2389は、機能一覧からサーバーの性質を推測できる点も認めていた。FEATがなくても個々の命令を試せば似た情報は得られるが、その探索はログ上で攻撃者を目立たせるかもしれない。文書は、その差を機能一覧を廃するほど重大とは評価しなかった。

重要なのは、一覧が何を語り、何を語らないかである。互換性に必要な範囲を安定した名前で示し、未知の追加を許す。安全性や権限は各機能の実行点で判断する。結果は実際の応答と状態で確認する。

RFC 2389は「何を話せるか」を「この依頼を引き受け、完了したか」から切り離した。最小限の共通記述が自律的な判断を助け、実行中の交換が最終的な証拠を出す。その順序こそが、拡張可能性を約束の水増しにしなかった理由である。

出典