Column

SNIによるドメイン制御の仕組みと限界 — ECH時代に向けて

ネットワークの基礎 #SNI#ECH#ドメイン制御

TLSを復号しないフィルタリングの判定材料としてたびたび登場するのが SNI です。「復号しないのに、なぜ接続先ドメインが分かるのか?」——その答えがSNIであり、同時に、この方式の限界もSNIの性質に由来します。この記事では、SNIの仕組みと、できること・できないこと、そしてECHによってSNIが見えなくなっていく流れまで正面から整理します。

SNIとは — TLSのどの段階で何が見えるか

SNI(Server Name Indication)は、TLSハンドシェイクの最初のメッセージ(ClientHello)に含まれるフィールドで、クライアントが「これから example.com と話したい」とサーバに伝えるためのものです。

なぜそんなフィールドが必要かというと、1つのIPアドレス(1台のサーバ)で複数のドメインのサイトを提供することが普通だからです。サーバは「どのドメイン宛か」を知らないと、正しいサーバ証明書を返せません。そして重要なのは、証明書を選ぶより前に伝える必要があるため、SNIは暗号化が始まる前——つまり平文で送られることです(従来のTLSでは)。

整理すると、TLS接続の冒頭では、経路上から次が見えます。

  • 宛先IPアドレス・ポート(L3/L4)
  • 接続先のドメイン名(SNI、平文)

その後の通信の中身は暗号化され、見えません。

SNIでできること — ドメイン単位の allow/deny

経路上の機器は、接続の冒頭でSNIを読み、通信を復号することなく「どこへ繋ごうとしているか」をドメイン名で判定できます。これにより、

  • 許可リスト型:許可したドメイン以外への接続を遮断する
  • 拒否リスト型:持ち出しに使われやすいサービスなど、特定ドメインへの接続を遮断する

というドメイン単位の制御が、証明書配布もTLS復号もなしに成立します。AIエージェントのように接続先が少なく安定したホストのegress 制御と相性がよいのもこのためです。

限界① — ホスト名単位であり、パス単位ではない

SNIで見えるのはホスト名(ドメイン名)までです。URLのパスやクエリは暗号化された中にあり、見えません。

つまり example.com/safeexample.com/danger は区別できず、同一ホスト上でパスだけが異なるWebhook・共有リンクの類も区別できません。制御の最小単位は「そのホストに到達させるか否か」です。

限界② — 共有CDN・共有ホスティングの曖昧さ

現代のWebでは、多数の無関係なサービスが同じCDN・同じクラウド基盤に同居しています。SNI自体はホスト名を正しく示しますが、運用上は次の曖昧さが生まれます。

  • 大手クラウドの汎用ドメイン(ストレージサービスなど)を許可すると、同じ基盤上の無数のテナントへの到達も許すことになりうる
  • ワイルドカードで広く許可するほど、意図しない宛先が紛れ込む余地が増える

「ドメインを許可する」とは、厳密には「そのドメイン名で到達できるすべてのものを許可する」ことだ——という感覚を持っておくと、許可リストの書き方が変わります。

限界③ — ECHでSNIが見えなくなる流れ

そして構造的な変化が ECH(Encrypted ClientHello) です。平文のSNIは経路上の誰からも見える——これは検閲・盗聴の観点ではプライバシー上の弱点でもあり、それを塞ぐためにClientHello自体(SNIを含む)を暗号化する仕様がECHです。主要ブラウザやCDNで対応が進みつつあります。

ECHが使われた接続では、経路上の機器は本当の接続先ドメインを読めなくなります。つまり「SNIで常にドメインが見える」という前提は、今後恒久には成り立ちません。SNIベースの制御を検討するなら、この流れは織り込んでおくべき事実です。

ECH時代への現実的な備え

ではSNIベースの制御は無意味になるのか——現時点での実務的な答えは「組み合わせで可視性を維持する」です。

  • ECHの鍵配布はDNSに依存します。ECHを使うにはDNS(HTTPSレコード)から鍵を取得する必要があり、その名前解決の経路を組織が管理していれば、ECHの利用自体を制御する余地があります。逆に DoH(DNS over HTTPS)で名前解決ごと暗号化されると、この制御点を失います
  • QUIC も同様に、検査側の対応状況によっては可視性を下げる要因になります

つまりECH時代のドメイン制御は、SNI単体ではなく DoH・QUICの制御とセットで設計することになります。この点はDoH・QUICと可視性の記事で詳しく扱っています。あわせて、ドメインで判定できない通信を既定でどう扱うか(通すか、止めるか)という方針を決めておくことも、設計の一部です。

まとめ

  • SNIはTLSハンドシェイク冒頭で接続先ドメインを伝えるフィールドで、(従来のTLSでは)平文で見える
  • これを使うと、TLSを復号せずにドメイン単位の allow/deny が成立する
  • 限界は3つ:ホスト名単位(パス不可)、共有CDNの曖昧さ、そしてECHによりSNIが見えなくなる流れ
  • ECH時代の備えは、SNI単体に頼らずDoH・QUICの制御と組み合わせて可視性を設計すること

Tate(盾)のドメイン制御もこの仕組みの上に立っており、ECH・DoHによる可視性低下を限界として明示しています。詳しくは用語集よくある質問をご覧ください。

AIエージェントの外向き通信、見えていますか。

Tate(盾)は、回線に挟むだけで導入できる L2透過型ファイアウォール・アプライアンスです。現在、先行案内・お問い合わせを受け付けています。