要約

  • SNIは宛先DNS名をTLSのClientHelloに載せ、共有アドレスのサーバーが暗号化HTTPより前に証明書とサービス設定を選べるようにした。
  • その名前は選択材料であり、本人性や権限の証明ではない。暗号化前に置かれたため経路から見え、ECHは公開する外側の名前と保護する内側の名前を分離した。

中身を開ける鍵を、中身を読む前に選ぶ

一つの受付に、別々の組織から届く封書が集まるとする。受付は封を開ける前に、どの組織の印章を示すべきか決めなければならない。ところが宛名は封書の中にある。手順を守るほど、選択に必要な情報へ届かない。

HTTPSでも同じ順序問題が起きた。RFC 2246のTLS 1.0は、認証と鍵共有を終えてから、保護されたアプリケーションデータを交換する。HTTPのホスト名は後半にあるため、証明書を選ぶ時点では利用できなかった。

2003年のRFC 3546はServer Name Indicationを定めた。クライアントがClientHelloで目的のサーバー名を先に伝えれば、共通のTLS入口は適切な証明書、暗号設定、背後のサービスを選択できる。

発明の核心は名前そのものではなく、名前を置く時刻にあった。役に立つほど早く、しかし今回の暗号ではまだ守れない場所である。

IPアドレスとサービスの身元をほどく

通常のHTTPは、要求を読んでからホスト名別に振り分けられた。TLSでは、その要求を読むための安全な経路を先に作る必要がある。SNIがなければ、証明書ごとにアドレスを用意する、多数の名前を一枚の証明書へまとめる、既定の証明書を返す、といった回避策が必要だった。

これらはアドレス配分、証明書更新、ホスティング構成を強く結び付ける。SNIは選択を二段階にした。DNSと経路制御が共有入口まで運び、ClientHelloの名前が入口の内側でTLSコンテキストを選ぶ。

この分離により、共有ホスティング、CDN、リバースプロキシ、クラウドの入口で複数のHTTPSサービスを扱いやすくなった。IPアドレスが不要になったのではない。一つのアドレスが一つの証明書身元だけを意味しなくなった。

案内札は身分証明書ではない

RFC 6066はserver_nameとDNS名用のhost_nameを整理した。サーバーが名前を認識できなければ、unrecognized_nameで終了しても、設定に従って続行してもよい。

この選択肢がSNIの限界を示す。名前を書いたからといって、クライアントに利用権が生じるわけではない。DNSの正しさも、選ばれた証明書の妥当性も保証しない。クライアントは証明書を検証し、アプリケーションは権限を判定し、後から届くHTTPの権威も接続文脈と照合する必要がある。

SNIは封筒の外側にある振り分け先であり、中の署名ではない。選択と認証を混同すると、広すぎる既定証明書やテナント間の誤配送を正当な接続に見せてしまう。

暗号化に役立つ名前が、暗号化より前に見えた

最初のClientHelloは、このハンドシェイクが鍵を生む前に送られる。その鍵で名前を隠し、同じ名前で鍵の準備を選ぶことはできない。元のSNIは循環を避けるため平文だった。

経路上の観測者はHTTP本文やURLを読めなくても、接続先のドメインを知り得た。RFC 8744は平文SNIのプライバシー漏えいと、監視、分類、フィルタリングなどの運用上の利用を記録している。

RFC 8446のTLS 1.3はServerHello以後のハンドシェイクを広く暗号化した。それでも最初のClientHelloは先に届く。問題は古い暗号方式だけでなく、依存関係の順序にあった。

見える値の周囲に制度が育つ

CDNはSNIで転送し、観測基盤はドメイン別に集計し、ネットワーク機器は許可や遮断を判断する。最初はTLS入口のための手掛かりだったものが、経路上の多くの主体にとって制御面になった。

そのため、名前の暗号化は一フィールドの変更では済まない。入口は、内側を復号できるサービスまで到達するための公開情報をまだ必要とする。一方、平文名へ依存してきた中間装置は、可視性の喪失を障害として扱うことがある。

技術上の必要と、長年見えていたから使っている慣行を区別しなければ、過去の漏えいが将来の暗号化を拒む根拠になる。

ECHは共通の表札と内側の宛先を分ける

2026年のRFC 9849はEncrypted ClientHelloを規定する。クライアントは機微な情報を持つ内側ClientHelloを作り、それを暗号化して外側ClientHelloに収める。外側の公開名はECH対応サービスまで接続を運び、実際のオリジン名は内側に残る。

IPアドレスと公開名は消えない。ECHはメタデータをゼロにする仕組みではなく、公開部分の精度を下げる仕組みである。複数のオリジンが共通の表札を使い、その奥で初めて正確な宛先を選べる。

受理、拒否、再試行の設定も明示される。クライアントは保護されたハンドシェイクでECHの受理を確認する。復号できないとき、外側の公開名が知らないうちに本来のオリジンへ化けてはならない。

古い順序問題への新しい答えは、保護境界まで運ぶ最小名だけを外に出し、正確な目的地は境界内で知らせることだった。

プロトコルの時系列は知る権限を配る

SNIは名前ベースのホスティングとTLSの認証順序を両立させた。同じアドレスで異なる証明書とサービスを運用しやすくし、共有HTTPSを特別な構成から日常的な基盤へ近づけた。

しかしSNI単独は名前を認証せず、権限を与えず、接続先を隠さない。有用性と露出は同じ早期配置から生まれた。ECHは公開経路を残しながら、詳細な名前を知る範囲を縮める。

歴史が示すのは、フィールドの意味だけでなく登場時刻が力を配分することだ。暗号化前に必要な情報は、その側にいる全員から観測され得る。境界を動かすには、外側の最小選択子を保ち、それを内側の権威と取り違えない設計が要る。

情報源と証拠の限界

規格上の根拠はRFC 2246、RFC 3546、RFC 6066、RFC 8446、RFC 8744、RFC 9849である。ホスティング費用、監視の誘因、移行上の依存についての記述はメッセージ順序からの分析であり、特定事業者の計測結果ではない。