この記事は約6分で読めます。

筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ

たった 1 行のバリデーションで防げる、CDN の落とし穴

if (TLS_SNI != HTTP_Host_Header) { reject(400); }

この 1 行のチェック を入れているかどうかで、CDN を導入したサービスが ドメインフロンティング攻撃（Domain Fronting） にすり抜けられるかが決まります。

情報処理安全確保支援士 令和4年春午後Ⅱ 問2 を解いている中で、この攻撃の構造に出会いました（前回記事で扱った「CDN は DoS ではなく DDoS 対策である」と同じ問題からの発見です）。

仕組みは TLS の SNI と HTTP の Host ヘッダーが異なる RFC で定義された別レイヤーの情報 であることに由来します。「HTTPS は HTTP の暗号化版」 という素朴な理解では、攻撃の隙が見えません。本記事では、図解付きで攻撃の仕組み・CDN の限界・1 行で実装できる対策まで整理します。

対象読者: 情報処理安全確保支援士の午後対策中の方 / CDN 導入を検討中のインフラ・SRE 担当者 / Web セキュリティの「レイヤーの違い」を意識して防御設計したい方

HTTPS と HTTP のリクエスト構造の違い

HTTP（TLS なし）の場合

クライアントが「どのドメインへのリクエストか」を伝える情報は Host ヘッダー だけです。Host ヘッダーは試験当時の規格 RFC 7230 で定義されており、2022 年 6 月にこれを置き換えた現行規格 RFC 9110 に引き継がれています。

GET /index.html HTTP/1.1
Host: example.com

補足: 試験問題（令和 4 年春＝2022 年 4 月）の出題時点では RFC 7230 が現行でしたが、その 2 か月後に RFC 9110 / 9112 が同セマンティクスを引き継ぐ形で標準化されました。本記事は両方を併記します。

HTTPS（TLS あり）の場合

TLS ハンドシェイクの段階で SNI（Server Name Indication、RFC 6066） によって接続先ドメインを通知します。サーバはこの SNI を見て、どの証明書を返すかを決定します。

[TLS ハンドシェイク]
  ClientHello {
    SNI: example.com   ← RFC 6066（TLS拡張）
  }
  ↓ サーバが SNI に基づき適切な証明書を返す
[TLS 確立]
  ↓
[HTTP 通信]
  GET /index.html HTTP/1.1
  Host: example.com    ← RFC 7230（HTTP仕様）

つまり HTTPS では、「TLS 層の SNI」と「HTTP 層の Host ヘッダー」の 2 箇所 にドメイン情報が出現します。

通常時: SNI と Host は一致する

一般的なブラウザは URL から自動的に SNI と Host の両方を同じドメインに設定します。https://example.com/ を開けば、SNI も Host も example.com です。利用者が意図的に異なる値を指定する手段はありません。

しかし、攻撃者は自前のクライアント（curl やスクリプト等）を使うことで、SNI と Host を独立に設定できます。

# 概念図: 攻撃者の自作クライアント
SNI         = front.example.com    ← TLS で「見せかける」ドメイン
Host header = hidden.example.com   ← 実際に取り出したい中身

この 2 つのレイヤーが別の情報を持てる という構造が、ドメインフロンティング攻撃の余地となります。

ドメインフロンティング攻撃の仕組み

CDN は通常 TLS 終端を CDN エッジで行い、TLS 解除後の HTTP 通信を内部ルーティングで各オリジンに振り分けます。SNI と Host が異なる場合、それぞれのレイヤーが異なる情報を見て判断する ことになります。

[攻撃者] ──── SNI=front.example.com ────→ [CDN エッジ]
                                            ├ TLS 終端（SNI で証明書選択）
                                            │    → front.example.com の証明書で通過
                                            │
                                            ▼
                                          [HTTP ルーティング]
                                            Host=hidden.example.com ← Host で振り分け
                                            ▼
                                       [hidden.example.com の中身を取得]

ポイント:

TLS 層 では SNI = front.example.com を見て、正規ドメイン向けの証明書を選択 → 暗号化セッション確立
HTTP 層 では Host = hidden.example.com を見て、本来の宛先とは別のオリジン へリクエストを転送
ネットワーク経路上の観測者（ファイアウォール、検閲システム等）は、暗号化前の SNI しか見えない ため、表面上は「正規ドメインへの通信」に見える

結果として、「TLS では正規ドメインに見せかけて、中身では別のドメインを呼ぶ」 攻撃が成立してしまいます。

CDN を入れただけでは防げない

CDN は本来「コンテンツ配信高速化」「DDoS 緩和」を主目的とした仕組みであり、SNI と Host の整合性チェックがデフォルトでは行われないサービスもありました。

そのため、検閲回避や C&C 通信の秘匿などにドメインフロンティングが悪用された経緯があり、Google・AWS・Microsoft などの主要 CDN ベンダーは順次対策を講じています（現在では多くの CDN がこの不一致を拒否する設定をデフォルト・もしくは選択可能にしています）。

対策: SNI と Host ヘッダーの一致を検証する

最も基本的かつ効果的な防御は、CDN エッジまたはオリジン側で SNI と Host を比較し、不一致なら拒否する ことです。

if (TLS_SNI != HTTP_Host_Header) {
    reject(400 Bad Request);
}

たったこれだけのバリデーションで、ドメインフロンティング攻撃の典型パターンは遮断できます。「同じドメインを指す情報が複数経路にある」 とき、その整合性を取らないと攻撃の隙になる、という普遍的な教訓でもあります。

「基本的だが見落としやすい」理由

観点	通常の認識	実際
TLS と HTTP	「HTTPS は HTTP の暗号化版」	TLS 層と HTTP 層は別レイヤー・別 RFC
ドメイン情報	「URL のドメインで一意に決まる」	SNI と Host はクライアントから独立に設定可能
CDN	「導入すれば安心」	整合性チェックを設定で塞ぐ必要がある

仕組み自体は RFC 6066（SNI）と RFC 7230（Host ヘッダー）を読めば導出可能 な内容です。しかし RFC を腰を据えて読む機会が少ないと、「SNI と Host が独立に設定可能」 という前提自体に気づきにくく、机上の知識だけではすり抜けやすい問題です。

試験で問われる視点

午後問題では「CDN 構成図に対して想定される攻撃と対策を述べよ」のような形で出題されます。

解答方針	正誤
「IP フィルタで攻撃元を遮断する」	✗（攻撃元は変動するため有効でない）
「TLS の暗号スイートを強化する」	✗（暗号は破られていない・本質ではない）
「SNI と Host ヘッダーの一致をエッジで検証する」	✓

「攻撃の構造を理解しているか」が問われています。「CDN を入れた = 安全」と短絡せず、どこに不整合の隙が残るか を構造的に説明できることが、午後問題で点を取るための土台になります。

まとめ

HTTPS には TLS 層の SNI（RFC 6066） と HTTP 層の Host ヘッダー（RFC 7230 → 現行 RFC 9110） の 2 箇所にドメイン情報がある
通常は両者は一致するが、自前クライアントで独立に設定可能
これにより、TLS では正規ドメインを装い、HTTP では別オリジンを呼ぶ ドメインフロンティング攻撃 が成立する
対策は エッジ/オリジンで SNI と Host の一致を検証する こと。実装は単純だが、設定漏れがあると CDN だけでは防げない

「導入したから安全」ではなく「設計で塞ぐべきギャップは何か」を意識する視点が、午後問題でも実務でも問われます。

参考

RFC 6066 — Transport Layer Security (TLS) Extensions — SNI 仕様の一次ソース
RFC 7230 — HTTP/1.1 Message Syntax and Routing — Host ヘッダー仕様（試験当時の現行・2022 年 6 月に obsolete）
RFC 9110 § 7.2 — HTTP Semantics: Host and :authority — Host ヘッダー仕様（現行）
情報処理安全確保支援士試験過去問題 — IPA 公式 — 令和 4 年春 SC 午後Ⅱ問題本文
情報処理安全確保支援士への道のり（随時更新中） — 学習記録・他分野の解説まとめ

関連記事

【支援士R4春午後Ⅱ】CDNはDoS対策ではなくDDoS対策である3つの理由 — 攻撃形態別の防御マッピング — 同じ R4 春午後Ⅱ問2 からの気づき第 1 弾
情報処理安全確保支援士への道のり(随時更新中)
マークダウン記法は奥深く、楽しい — テキストだけで「伝わるドキュメント」を作る技術