特にgoogle.com自体を担当するGoogleサーバーのILVをブロックするコンテキスト、およびその後のGoogleおよびAWSがドメインを使用してロックをバイパスすることを禁止するコンテキストで、ドメインのフロントについて聞いたことがあるでしょう。
ドメインカバーとは何ですか？
ドメインフロンティング、または無料翻訳では、ドメインカバーは、CDNの機能を使用して、フィルターとロックをバイパスし、接続の最終目標を隠す方法です。 現代のCDNには互いに独立して存在する2つの主要部分が含まれており、原則として相互にTCP接続を確立するという点でのみ相互に作用するため、この方法が可能です。
- SSL証明書データの転送との安全な接続の確立を担当する外部部分があります。
- 復号化後に直接送信された要求の処理を担当する内部部分があります。 通常、HTTP要求。
これらの2つの部分は相互に接続されていないため、最初の部分にアクセスするときに1つのサイトを参照し、安全な接続を確立した後、別のサイトにリクエストを送信できます。 これがプライベートCDNに関係する場合、通常は問題はありませんが、内部リソースへのアクセスという形でまれな例外があり、通常はアクセスできません。 これが、AWS CloudFrontや他社の類似品など、メンバーシップを購入できるパブリックCDNに当てはまる場合、すべてがすぐに興味深いものになります。
検閲者がCDNを認識する方法
検閲のタスクは、リストから特定のリソースへのアクセスを制限することです。 単純なHTTPの場合、特定のページアドレスが正確であっても、このタスクは特定の問題を引き起こしません。 もちろん、このような単純なタスクであっても、 ブロッキングを回避するための多くの美しい方法を生み出す愚かなミスの幅広い分野があります。これは、さまざまな通信問題に対するネットワークの基本的な安定性のために可能です。ネットワークの批判。
暗号化を使用する場合、タスクはより複雑になります。 特定のページアドレスをブロックすることはできなくなります。 HTTPSでサイトをブロックするタスクの最も簡単なソリューションは、IPによるブロックです。 CDNを使用しない場合でも、このタスクには多くの非常に不快な副作用が含まれます。 CDNを使用すると、IPによるブロックが不可能になることがよくあります。CDNの1つのIPに多くのサイトがあるため（ILVはこれまで停止していません）、それほど多くはありませんが、CDNのサイトは多くの異なるIPを持つことができるため、事前に知ることは不可能です。
検閲官は、安全な接続をセットアップする前に、常に行きたいサイトの名前をプレーンテキストで送信する最新のブラウザの助けになります。 プロバイダーおよびキャリアDPIは、どのサイトが接続しているかを簡単に確認してから、切断するか、干渉します。
実験
検閲者が接続設定をどのように認識し、どのように検閲を指の周りに回すことができるかを見てみましょう。 tsharkはtsharkを使用しますが、 tcpdumpまたはWiresharkのGUI を使用して同じデモを実行できます 。
実験では、この記事を読んだ同じサイトを使用します。これは、検閲を回避するこの方法を示すために必要なすべての機能を備えたQRATORのCDNの背後にあるためです。 このデモ自体は、使用するQRATOR CDNにセキュリティの脆弱性または問題があることを意味するものではありません。すべてのCDNがこれまでに機能し、ほとんどのCDNが引き続き機能します。 まったく同じ機能は、たとえばYandexのCDNにもあります。
1つのコンソールで、次を実行します。
tshark -T fields -Y 'tcp.dstport == 443 and ssl.handshake.extensions_server_name' -e ssl.handshake.extensions_server_name
tsharkがsudoなしで動作したくない場合...Debianでは、この問題は次の3つのコマンドで修正されています。
sudo dpkg-reconfigure wireshark-common sudo gpasswd -a $USER wireshark newgrp wireshark
YMMVの他の配布の下。 他のものが等しい場合、sudoを使用します。
隣接するコンソールで、HTTPSを介していくつかのサイトにアクセスします。
curl -sI https:
ログの最初のコンソールには、HTTPSを使用しているにもかかわらず、アクセスしたばかりのサイトの名前が表示されます。
Capturing on 'eno1' habr.com
検閲への驚き
SNIロギングを閉じずに、cURLが送信するリクエストをエミュレートしてみましょう。
(echo HEAD / HTTP/1.1 echo Host: habr.com echo Connection: close echo) | openssl s_client -quiet -servername habr.com -connect habr.com:443
curl -sI https://habr.com呼び出すと、以前と同じ答えが表示されcurl -sI https://habr.com 。 tsharkの出力は同じです。habr.comへの接続が記録されます。
そして今、リクエストヘッダーを変更せずに、habr.comではなく、古いサイト名に従っています：
(echo HEAD / HTTP/1.1 echo Host: habr.com echo Connection: close echo) | openssl s_client -quiet -servername habrahabr.ru -connect habrahabr.ru:443
驚き、驚き！ 以前とまったく同じ答えが得られましたが、 tsharkログとopenssl s_clientの出力では、 openssl s_client意味しています。
depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = habrahabr.ru
同じトリックを反対方向に行うことができます。
(echo HEAD / HTTP/1.1 echo Host: habrahabr.ru echo Connection: close echo) | openssl s_client -quiet -servername habr.com -connect habr.com:443
ログはhabr.comにアクセスしたことを示しますが、答えは結論に対応します。
curl -I https:
単一のHabrではない
遠くまで行かないように、独自のCDNを使用するYandexサイトでもまったく同じトリックが機能します。
(echo GET / HTTP/1.1 echo Host: music.yandex.kz echo Connection: close echo) | openssl s_client -quiet -servername music.yandex.ru -connect music.yandex.ru:443 | grep -Eo '<meta[^>]*?og:url[^>]*?>'
検閲官のログには、music.yandex.ruにアクセスしたことが示され、チームにはmusic.yandex.kzのメインページが開かれたことが示されます。
<meta property="og:url" content="https://music.yandex.kz/home"/>
ここで何が起こっていますか？
フローチャートでは、クエリは次のようになります。
接続の観点からは、たとえばgoogle.comなどの1つのサイトに接続しますが、 HTTP プロトコルの観点からは、同じCDNにある場合にのみ完全に異なるサイトにリクエストを送信します。
（上記の図は、問題の履歴、考えられる代替案、およびドメインカバーの使用に関するその他の詳細を調べる英語の大規模なレビュー記事からのものです。）
何が言えますか？
実際には、HTTPSのリクエストを1つのサイトに送信できると確信しており、検閲官は、まったく別のサイトに変更したことを確認します。 このようにして、Signalはエジプトと他の国で1年以上ブロックを回避し、 google.comの背後に隠れて 、最初にGoogle、 次にAmazonが検閲を回避するためにサイトと顧客のサイトを使用することを禁止しました。
Telegramは、この検閲回避方法も使用します。 希望する人は、公式クライアントのソースで、これがTelegramでどのように行われているか、どのCDNが使用されているかを正確に見つけることができます。
HabrとYandexのCDNのドメインカバーから、同じCDNを使用する独自のサイトがない場合、実際的なメリットはまったくないことは明らかです。したがって、繰り返しますが、CDNのこの機能は、任意のCDN自体の脆弱性とはまだ見なされていません。 レポートを取得するためにHackerOneで実行するのを急がないでください。
この状況は、ある程度最新のCDNのほとんどが他の誰かのドメインをカバーするために使用できるという事実につながります 。
すべての検閲者がブロックすることを決定したわけではないCDNでホストされている評判の高いドメインを見つけるタスクには、時間と忍耐だけが必要です。 たとえば、CDNには、media.tumblr.com、images.instagram.com、cdn.zendesk.com、cdn.atlassian.comなどの多くの人気ドメインがあり、ドメインのカバーに使用できます。 このような人気のある、したがって適切なドメインが不足することはありません。
GoogleとAmazonは悪に仕えていますか？
正当な問題が発生します。GoogleとAmazonが検閲を回避することを望まない場合、それは彼らが世界的な悪に仕えていることを意味しますか？ 検閲を回避するだけでなく、 侵入時の不正なリモートアクセスにもドメインカバーを使用するという事実があるため、この答えに明確な答えはありません。
もちろん、グーグルとアマゾンは、クラッカーなど、汚いビジネスに適切なドメインを使用するその他の犯罪要素とは関係ありません。
最後の観察結果は、残念ながら、他のすべてのCDNが徐々にGoogleとAmazonに追随し、検閲とブロックを回避するための説明されたオプションを禁止または制限することを期待できることを示唆しています。
独自のCDNを管理している場合は、だれかが同様の不適切な目的でサービスを使用できるかどうか、およびそれについてどう思うかを検討してください。 禁止しない場合は、少なくともこのようなことが自分の領土でできることを知っておく必要があります。