Peter Saint-Andre：証明書照合はサービスを選べない

要約

RFC 9525には二種類の識別子がある。サーバーはPKIXの末端証明書で提示識別子を示す。クライアントは、受け入れてよいと事前に考えた参照識別子を持つ。検証は両者の間に一致を探す作業だ。

参照側まで証明書から作れば、検証は循環する。サーバーが名乗った名前をその場で期待値に採用すれば、自己申告した条件で自ら合格できる。そのため、クライアントは提示識別子とは独立に参照リストを構築する。

参照識別子は、ソースドメインと必要に応じてアプリケーションサービス種別から作られる。DNS-ID、IP-ID、SRV-ID、URI-IDのどれを採用するかはプロトコルとローカル方針による。単にホスト名らしく見える文字列を集めたリストではない。

一致した場合、クライアントは一致した参照識別子を検証済みサービスアイデンティティーとして使う。証明書が期待を満たしたのであり、証明書が期待を発明したのではない。

ソースドメインは、利用者が入力したURL、アカウント設定、リンク、その他のアプリケーション情報から得られる。管理者が配った設定と、不審なメッセージに埋め込まれたリンクでは、文字列の形が同じでも権威が違う。

フィッシングのリンクを選べば、クライアントは攻撃者のサービスに整合する参照識別子を作り得る。そのサービスが正規に発行された証明書を持てば、照合は正しく成功する。TLSが壊れたのではなく、意図の入口が先に置き換わった。

証明書には、リンクの送り主、承認された設定、利用者の本来の目的は見えない。「この提示名は参照名と一致するか」には答えられるが、「参照名を選んだ理由は正しいか」には答えられない。

アプリケーションやプロトコルは、参照の生成方法を明文化する必要がある。許すURIスキーム、サービス種別への対応、安全な文脈を必要とする入力、受理する識別子型を決める。実装の偶然に任せると、認証の起点が監査不能になる。

DNSや発見処理は、元の名前から別名、ターゲット、アドレスへ進む。途中の名前は実際に接続を受ける設備を指すため、証明書の識別子にも見える。しかしRFC 9525は、それだけで参照識別子へ昇格させない。

アプリケーションが中間値を認証して採用する手順を別に定めることはできる。定めがなければ元の参照を保つ。経路を決める権限と、サービスの意味を決める権限を分けるためだ。

委託運用では、この差が実務になる。元のドメインが別会社の設備へ通信を送っても、クライアントは元のサービスを期待している。接続先の設備名だけを照合すれば、利用者が選んだサービスではなく配線を認証してしまう。

RFC 9460のSVCBとHTTPSレコードは、AliasModeによる運用委譲や、ServiceModeによる代替エンドポイントと接続パラメーターを提供する。それでもoriginと検証権威は変わらず、TLS証明書は元のサービス名に対して検証される。

HTTPSではSNIとHTTP authorityもoriginを示し、TargetNameを示すのではない。TargetNameは接続を試す場所、originは誰のサービスとして接続するかを表す。

監視で両方を一つの「ホスト」へ潰すべきではない。接続先だけならサービスの意味を失い、originだけなら実際に通信を受けた設備を失う。二つを残して初めて、負荷分散や障害迂回をアイデンティティー変更と区別できる。

DNS名は定められたラベル単位で比較され、IP-IDはオクテットが完全一致しなければならない。SRV-IDやURI-IDではサービス種別も比較対象になる。別々の参照からドメインとサービス部分を寄せ集めて、新しい受理条件を作ることはできない。

ワイルドカードを認める場合も、一個だけが左端ラベル全体を占め、一階層だけに一致する。これは照合範囲を定める規則であって、該当する全ホストの運用品質や所有者を保証する印ではない。

複数の参照識別子を許せば、どれか一つの一致で検索は成功する。柔軟性と同時に受理面が広がるので、認証局の名前制約が各識別子型にどう働くかまで確認する必要がある。

RFC 9525は末端証明書にあるサービス名を扱う。認証パスを作成・検証する文書ではない。有効期限、失効、トラストアンカー、鍵用途などの確認は別に必要で、名前が一致しても証明書全体は拒否され得る。

URIのpathやquery、アプリケーション資源への権限、サーバーの振る舞い、処理結果も照合対象ではない。TLS 1.3はアプリケーションプロトコルから独立しており、上位層が証明書をどう解釈するかを決める。

多数の名前を持つ証明書は、侵害時の範囲も共有する。その証明書を使えるサーバーの一つが弱ければ、集合内の他の名前へ影響し得る。一致は名前が集合に入っていることを示すだけで、各運用主体の強さまでは示さない。

一致しない場合、自動クライアントは通信を終了するのが原則で、人が操作するクライアントも警告後に終了すべきだ。その場の例外や即席のpinは、敵対的な状況で安全制御を外す行為になり得る。

成功時にも、入力、ソースドメイン、サービス種別、生成された参照一覧、発見の各段階、実接続先、提示識別子、一致項目、パス検証と失効確認を残すべきだ。比較結果だけでは、正しい名前を正しく比べたのか、誤った名前を正しく比べたのか分からない。