サムネイル|TLS暗号化が確立された後、HTTPヘッダーは同一CDN上にホストされた別のドメインへとリダイレクトされる。 ドメイン・フロント（） とは、するための技術であり、HTTPS接続において通信層ごとに異なるドメイン名を使用することで、第三者による監視から実際の接続先ドメインを秘匿する手法である。
この技術は、セキュリティ証明書の仕様上の特性、ドメイン・フロントとして機能するコンテンツ配信ネットワーク（CDN）のリダイレクト機構、そしてHTTPSによる暗号化の保護により、検閲者が回避用トラフィック（ドメイン・フロント経由）と通常のトラフィックを区別することが困難になるという特徴を持つ。その結果、検閲者は対象ドメインへのすべての通信を許可するか、あるいはドメイン・フロント自体を完全に遮断するかの選択を迫られる。後者の措置は、広範な副次的被害をもたらす可能性があり、「インターネット全体を遮断するようなもの」とも比喩される。
ドメイン・フロントは、HTTPのHostヘッダーとTLSのSNI（Server Name Indication）拡張との不一致によって実現される。SNI拡張を定義する標準では、このような不一致を推奨していないが、明示的に禁止しているわけではない。Amazon、Microsoft、Googleなどの大手クラウドサービス事業者は、ドメイン・フロントを積極的に禁止しており、これにより検閲回避技術としての利用は制限されている。ロシアや中国の検閲機関からの圧力が、こうした禁止措置の一因と考えられているが、ドメイン・フロントは悪意ある目的にも利用可能である。
ドメイン・フロントの新たな派生技術として「ドメイン・ハイディング（Domain hiding）」がある。これは、あるリソース（例：ウェブサイト）への暗号化されたリクエストを、同一クラウド内にDNS情報が保存されている別のリソースへの平文リクエストの背後に隠して送信するもので、同様の効果を持つ。より広範な原理の応用例としては「」が挙げられる。
技術的詳細
原理 ドメイン・フロントの原理は、大規模なホスティング事業者やコンテンツ配信ネットワーク（CDN）のサーバーとの通信において、通信層ごとに異なるドメイン名を使用することにある。これらのサーバーは複数のターゲットドメインをサポートしており（Subject Alternative Names）、CDNが採用するトラフィックおよびリクエストのルーティング方式の特異性が、ドメイン・フロントの成立を可能にしている。
リクエストの難読化 HTTPSリクエストにおいて、接続先のドメイン名は通常、DNSクエリ、TLSのSNI（Server Name Indication）拡張、そしてHTTPSのHostヘッダーという3つの箇所に現れる。通常は、これらすべてに同一のドメイン名が記載される。
ドメイン・フロントを用いたHTTPSリクエストでは、平文で外部に現れるドメイン（DNSクエリおよびSNI拡張に記載されるもの）と、暗号化された内部に隠されたドメイン（HTTPS Hostヘッダーに記載されるもの）が異なる。前者は検閲者に可視であり、接続先として偽装されるが、後者が実際の接続対象であり、HTTPSによって秘匿される。# wget は www.google.com にDNSクエリを送り接続するが、 # HTTP Hostヘッダーでは www.youtube.com を要求する。 # www.google.com は www.youtube.com のページを取得して表示可能である。 wget -q -O - https://www.google.com/ --header 'Host: www.youtube.com' | grep -o '<title>.*</title>' <title>YouTube</title>HTTPSプロトコルによってHostヘッダーが暗号化されるため、回避用トラフィックは通常のトラフィックと区別がつかない。ドメイン・フロントの実装では、大規模なコンテンツ配信ネットワーク（CDN）をフロントドメインとして利用する。これらのCDNはウェブの広範な部分で機能提供に使用されているため、検閲者が回避用トラフィックを遮断するには、フロントドメイン自体を遮断する必要がある。だが、主要なCDNの遮断は経済的・政治的・外交的に困難である。
2018年4月、ロシアにおいて裁判所命令に基づきTelegramが遮断された際、Telegramが使用していたCDN（Amazon Web Servicesなど）を遮断するために、GoogleおよびAmazonのCDNに関連するIPアドレス約1580万件が巻き添えで遮断された。これにより、主要銀行、小売チェーン、複数のウェブサイトに大規模なが発生し、遮断手法は「無能」と批判された。
リクエスト転送の活用 CDNは、1つのリクエスト内に異なるドメインが含まれていた場合でも、Hostヘッダーに記載されたドメインへのアクセス要求を自動的に処理するよう構成されている（あるいは過去にはそうであった）。この挙動はすべてのホスティング事業者に共通するものではなく、HTTPリクエストの各層で同一のドメインが使用されているかを検証するサービスも存在する。こうした場合には、SNIフィールドを空白にする「ドメインレス・フロント（domainless fronting）」という変法が有効となる可能性がある。
Hostヘッダーのドメインへのアクセスが成功した場合、検閲者や第三者の監視者には、CDNが内部的にリクエストを無害なページへ転送したように見える。回避シナリオでは、Hostヘッダーのドメインはプロキシであり、直接アクセスすれば検閲対象となるが、フロントを通すことでそのアドレスが秘匿され、ブロックを回避できる。DNSクエリおよびSNI拡張に記載されたフロントドメインには、実際にはトラフィックは到達しない。CDNのフロントエンドサーバーのみがHostヘッダーを復号し、真の接続先を認識できる。自動転送を行わないホスティングサービスでも、「リフレクター」型のウェブアプリケーションを用いることで同様の挙動を再現可能である。
一般的に、ウェブサービスは自社顧客のドメインに対してのみリクエストを転送する。したがって、ドメイン・フロントを利用する遮断対象ドメインは、フロントとして使用する無害なサイトと同じ大手プロバイダーにホストされている必要がある。
ドメイン・ハイディング TLS（Transport Layer Security）による一般的な安全なインターネット接続では、最初の通信メッセージは暗号化されておらず、クライアントがサーバーに接続要求を送信する。この後、サーバーとクライアントは暗号化された接続を交渉し、実際の通信内容は暗号化される。これにより通信内容は秘匿されるが、通信のメタデータ、誰が誰に、いつ、どれだけ通信しているか、は可視のままである。
ドメイン・フロントの派生技術である「ドメイン・ハイディング（Domain hiding）」では、あるリソース（例：ウェブサイト）への暗号化されたリクエストを、別のリソースへの平文リクエストの背後に隠して送信する。両リソースのDNS情報が同一クラウド内にホストされている場合、インターネットサーバーは平文アドレスを読み取り、リクエストをクラウドに転送する。クラウドサーバーは暗号化接続を交渉し、平文アドレスを無視して、暗号化チャネル上で送信された別のアドレスにメッセージを届ける。第三者がこの接続を監視しても、平文しか読み取れず、実際の接続先を誤認することになる。
利用例
インターネット検閲の回避
Lantern は、ドメイン・フロントの影響を受けた。
Signal セキュアメッセージングサービスであるSignalは、2016年から2018年にかけて、エジプト、オマーン、カタール、アラブ首長国連邦における自社サーバーへの直接接続の遮断を回避するために、アプリにドメイン・フロントを実装した。
Tor Tor匿名ネットワークは、ドメイン・フロントの実装として「meek」と呼ばれるプラッガブル・トランスポートを採用し、Torネットワークへの接続遮断を回避している。
Telegram Telegramは、ロシアにおける遮断への抵抗手段として、Amazon Web Servicesをドメイン・フロントとして使用した。
Telex もドメイン・フロントの影響を受けた。
GreatFire 中国の「グレート・ファイアウォール」回避を支援する非営利団体は、かつてドメイン・フロントを利用していた。
サイバー攻撃 ドメイン・フロントは、民間および国家支援の個人・団体によって、痕跡を隠しつつサイバー攻撃を実行したり、マルウェアを拡散したりする目的でも使用されている。
Cozy Bear ロシアのハッカー集団（APT29）は、CDNからの正規トラフィックを装うことで、システムへの不正アクセスを秘匿するためにドメイン・フロントを使用していたとされる。彼らはTorプロジェクトが開発した「meek」プラグインを用いて、検出を回避していた。
無効化 ドメイン・フロントが検閲回避手段として長く利用されてきた背景には、遮断による高額な副次的被害がある。ドメイン・フロントを遮断するには、フロントとして機能するCDNや大手クラウド事業者へのすべての通信を遮断する必要があるが、これらは設計上、無数のウェブサービスに依存されている。は、「1つのドメイン・フロントされたサイトを遮断するには、インターネット全体を遮断する必要がある」と例えた。
ロシアは、メッセージングアプリTelegramがドメイン・フロントを使用していたことから、GoogleおよびAmazonのサーバー全体を遮断しようとした。これにより、GoogleおよびAmazonクラウドを利用していた銀行サイトやモバイルアプリなど、無関係な多数のウェブサービスが巻き添えで遮断された。結果としてTelegramの遮断には失敗した。遮断措置は2018年4月13日に開始された。
2018年4月14日、Googleは自社クラウドにおいてドメイン・フロントを静かに無効化し、4月27日にはAmazonが同様の措置を発表した。Cloudflareもこれを遮断し、アカマイ・テクノロジーズも影響を受けた。Microsoftは当初追随しなかったが、2021年3月にMicrosoft Azureクラウドにおいてドメイン・フロントを禁止する方針を発表した。
Cloudflareは2015年からすでにドメイン・フロントを無効化していた。
2018年4月、GoogleとAmazonは、コンテンツ配信サービスにおけるリダイレクト方式の特異性を排除することで、ドメイン・フロントを無効化した。Googleは、CDN構造を変更することで「google.com」をフロントドメインとして使用できないようにした。Googleは、ドメイン・フロントは「公式にサポートされた機能ではなかった」とし、今回の変更は以前から計画されていたアップグレードであると説明した。Amazonは、ドメイン・フロントは「すでにAWS利用規約違反として扱われていた」とし、他サイトのCloudFrontドメインを偽装して使用することを禁止する変更を実施した。
反応 複数の報道機関は、GoogleおよびAmazonによるドメイン・フロント遮断の動きが、ロシア政府および通信監督機関Roskomnadzorによる圧力の影響である可能性を指摘している。Roskomnadzorは、TelegramがGoogleおよびAmazonのドメインをフロントとして使用していたことを理由に、2018年4月に数百万件のドメインを遮断した。
デジタル権利擁護団体は、この措置が抑圧的な国家において、人々が自由かつ安全に情報へアクセス・発信する能力を損なうと批判している。
Signalの創設者によれば、Googleの経営陣は、Signalのようなアプリがドメイン・フロントを実装したことで注目を集める中、国家規模で遮断対象となるサイトやサービスのフロントとして機能することに疑問を抱くようになったという。彼は、検閲回避ツールにおけるドメイン・フロントの使用は「もはや必要とされる国々ではほぼ実用不可能」と述べた。ただし、TorやLanternなど一部のサービスでは現在も使用されている。
関連項目 Server Name Indication
脚注
参考文献 （英語）