要約

  • HTTP 511は、広いネットワークへ出る前に接続側の条件を満たす必要があると知らせる。要求先のオリジンではなく、接続を制御する介在プロキシが使うための状態コードである。
  • 応答はログイン画面を要求先URLの文脈に埋め込まず、別の操作先へリンクすべきだ。511は誤認を減らせても、介在者を信頼できる存在に変えず、TLSの証明書問題も解消しない。

URLが示す相手と、実際に話した相手

端末が新しいネットワークにつながると、バックグラウンドのアプリは普段どおり通信を始める。天気情報を取りに行ったはずの接続に、ホテルや空港の利用同意画面が返ることがある。人間なら「先にWi-Fiへログインするのだ」と読み替えられる。しかし更新確認や同期処理は、そのHTMLを壊れたAPI応答として扱うしかない。

ここで起きているのは単なる画面遷移ではない。要求のURLはオリジンを名指ししているのに、経路のネットワークが自分の都合をその返答欄へ書き込んでいる。自動クライアントは内容をキャッシュしたり、解析エラーを起こしたり、リダイレクトの先でも元の処理を続けたりする。

RFC 6585が2012年に定めた 511 Network Authentication Required は、この介入に固有の名前を与えた。クライアントがネットワーク利用の条件を満たしていないこと、そしてその通知者がオリジンではなく接続を遮断できる介在プロキシであることを表す。

ネットワークへの入場とサービスへのログインは別物

「認証」という同じ言葉でも、関係する主体は異なる。ウェブサービスは自分の資源に対するアカウントを確認できる。接続ネットワークは料金、規約への同意、施設利用者の登録などを求められる。片方が他方の名前で要求を出す権利はない。

そのためRFC 6585は、オリジンサーバーが511を生成すべきではないとする。アプリケーションの資格情報には通常の認証・認可の仕組みがあり、511はあくまで通信経路が課した前提条件を示す。サイトのパスワードを直しても問題が解けないとクライアントに伝える境界線でもある。

511そのものが証明できる範囲は狭い。接続制限の存在は伝えられるが、施設の条件が正当か、ポータルの運営者が信頼できるか、端末を操作している人が誰かは証明しない。

フォームではなくリンクにする意味

RFC 6585は、511の表現から資格情報を提出する資源へリンクすることを勧める一方、応答の中に認証チャレンジやログイン画面自体を置かないよう求めている。

ブラウザーは、ユーザーが開こうとしたURLの文脈で受け取った内容を表示する。そこにパスワード欄が現れれば、要求先サイトが秘密を求めているように見える。経路上の装置による要求だと気づけない利用者もいる。

別URLへのリンクは、操作を独立した名前へ移す最低限の仕切りになる。ただし、リンク先が安全だという保証ではない。実際のホスト名を示し、TLS証明書を検証し、ネットワークが扱う権限のある情報だけを求める必要がある。511はログイン完了ではなく、別の権限主体への引き渡しを表す。処理後には、本来の要求をオリジンへ送り直さなければならない。

ブラウザー以外には「気の利いた案内」にならない

RFC 6585は511を、キャプティブポータルが引き起こす損害、特にブラウザーでないエージェントへの損害を和らげるものとして説明する。介入を推奨しているわけではない。

更新プログラムにとって、マニフェストの代わりに届くHTMLは破損データである。同期クライアントにとって、WebDAV応答の代わりに届く同意画面はプロトコル違反である。リダイレクトしても、ソフトウェアが追従し、ポータルの出力を元の処理系へ持ち込む可能性が残る。

HTTPが多くのアプリケーションの土台になるほど、一律の差し替えは運用者の理解しない境界へ広がる。専用の状態コードがあれば、対応クライアントはオリジン作業を中断し、誤った内容の保存や状態変更を避けられる。

一時的な拘束をキャッシュで持ち越さない

511応答はキャッシュしてはならない。制限は、特定の接続先、端末のセッション、時刻に結び付く。保存されれば、認証後にも古い制限が残り、別のネットワークへ移動した端末にも付きまとう。さらに、ネットワークの主張がオリジンの状態であるかのように再利用される。

現在の許可状態を判断できるのは、その時点の接続制御系だけだ。キャッシュには介入を延長する権限がない。

TLSは身代わりを見逃さない

平文HTTPなら、介在装置は応答を置き換えて511を付けられる。HTTPSではその前に、クライアントがTLSでサーバー名を検証する。ポータルは要求先オリジンの証明書を持たないため、正しいハンドシェイクを完了できない。RFC 6585も、HTTPSの介入では証明書エラーになると指摘する。

つまり511は、ポータルが正直には成立させられないTLS接続の内側から出すことができない。証明書警告を抑えて画面だけを見せるなら、ネットワークにオリジンの人格を与えることになり、状態コードの意図と逆行する。

問題は証明書だけではない。介在者は平文の認証情報を観測し、オリジンの名前空間に属するCookieへ干渉できる。511を使っても使わなくても、キャプティブポータルにはこの危険がある。正確なエラー名は危険な経路を安全にはしない。

驚かせる検出から、通知された状態取得へ

RFC 8952のCaptive Portal Architectureは、仕組みを分業させた。プロビジョニングが端末へAPIの場所を知らせ、APIが状態を返し、ユーザーポータルが操作を受け、エンフォースメント装置が通過可否を決める。RFC 8908は、そのHTTPS APIを定義している。

端末は、無関係な平文サイトへの「カナリア」要求が改変されるのを待たず、ネットワーク参加時にAPI URIを得られる。APIサーバーの証明書を検証し、自分の接続状態を問い合わせる。応答には必須の captive 真偽値があり、必要に応じてHTTPSのユーザーポータルURLも含まれる。

利用者が操作を終えた後、端末はもう一度APIへ問い合わせて制限解除を確認する。フォーム送信やリダイレクトの成功だけで開通を推測しない。APIとエンフォースメントが同じ端末を指していることも必要である。

旧来の方式がすぐ消えるわけではなく、端末識別の結び付けにも難しさは残る。それでもネットワークの主張を、ネットワーク自身が運営する名前と認証済みの通信路へ移せる。無関係な天気サイトが検出装置の代役を務める必要はない。

511が伝えられる、細いが重要な事実

511はポータルを認証せず、介入を正当化せず、TLSを回避せず、人間が同意したことも証明しない。オリジンが401や403の代わりに使うものでもない。貢献は限定的だが明確だった。ネットワーク利用条件の発信元を接続側として示し、その要求が再利用可能なオリジン応答に見えるのを防ぐことである。

後のAPI設計も同じ原則を延ばした。権限を持つ者は、自分の名前で話すべきだ。ネットワークには転送を止める力がある。その力を説明するために、宛先の声を借りる必要はない。

出典