Appendix A. Design Rationale (付録 A. 設計理由)

Appendix A. Design Rationale (設計理由)

TLS ALPN チャレンジは, 初期の ACME ドラフトで定義された TLS SNI チャレンジを改良するために存在する. TLS SNI チャレンジは, 検証を TLS 層のみで実施したい大規模な TLS 層ロードバランシングシステムを運用するサービスプロバイダ, または単一ホストで多数の DNS 名を前段で扱うサーバを運用するサービスプロバイダにとって便利であった. TLS SNI チャレンジが提供する価値は十分大きいと考えられ, 既存のセキュリティ上の懸念に対処する新しいチャレンジ型を提供するために本ドキュメントが作成された.

Frans Rosen により TLS SNI チャレンジのセキュリティ問題が発見され, さまざまなサービスプロバイダのユーザーが, 同一プロバイダの他のユーザーの DNS 名の制御を不当に検証できるようになっていた. TLS SNI チャレンジが設計された際, ユーザーはサービスプロバイダに登録したドメイン名に対する SNI を介した TLS トラフィックにのみ応答できると仮定されていた (すなわち, ユーザーが a.example を登録した場合, a.example の SNI リクエストにのみ応答でき, b.example の SNI リクエストには応答できない). 多くの大規模サービスプロバイダはこの性質を満たさないことが分かった. このため, ユーザーは TLS SNI チャレンジ検証プロセスで用いられる名前への SNI リクエストに応答できた. これは, (1) ユーザー A とユーザー B がそれぞれホスト A とホスト B を登録していた場合, ユーザー A がホスト B 向けに構築された SNI チャレンジ名を主張でき, (2) 検証接続が行われた際にユーザー A が応答し, ホスト B の「制御」を証明できたことを意味する. 用いられた SNI 名は検証対象のドメイン名そのものではなくサブドメインであったため, トラフィックルーティング用にサービスプロバイダに未登録である可能性が高く, ハイジャックが起きやすかった.