HTTPSの自動リライトで混在コンテンツの問題を修正する

Cloudflareは、暗号化されていないインターネットに終止符を打つことを目指しています。しかし、WebのHTTPSの移行については、ニワトリとタマゴのように、どちらが先かと言う問題があります。

昔は、HTTPSケーブルWebサイトをセットアップすることは、困難で、高価で、時間がかかることでした。そこで登場したのが、CloudflareのUniversal SSLのような、http://からhttps://への移行を、ボタン1つをクリックするだけで簡単にできるサービスです。ワンクリックで、無料の新しいSSL証明書を発行して、サイトをHTTPSで提供できるようになりました。

ここで大きな変化がもたらされます。

突然、WebサイトはHTTPS経由で利用可能になり、最新のWebプロトコルであるHTTP/2を活用することができるようになったことで、Webサイトは高速化しました。

しかし、話はここで終わりません。他の面では安全な多くのサイトが、混合コンテンツの問題に頭を悩まされることになりました。また、混合コンテンツは、完全に安全とは言い切れないため、https://サイトに緑色の南京錠が表示されません。

そして、問題が起きるのは、https://のWebサイトに http://経由で配信されたサイト（サイト独自のものも含む）コンテンツが含まれている場合です。その場合は、緑色の鍵マークが表示されません。これは、画像、JavaScript、オーディオ、ビデオなどのリソースが http://経由で組み込まれている場合、安全なWebサイトにセキュリティホールを作ってしまうためです。問題の侵入経路（バックドア）になるのです。

Webブラウザはこれが問題であることを、実に長い間認識してきました。1997年まで遡ると、Internet Explore 3.0.2は、次のダイアログボックスを使用して、サイトユーザーに混在コンテンツを警告していました。

現在、Google Chromeでは安全でないコンテンツが含まれるhttps: //では、マルで囲んだ「i」が表示されます。

また、Firefoxでは、警告のマークが書かれた南京錠が表示されます。これらのブラウザで緑色の南京錠を表示するには、すべてのサブリソース（ページによって読み込まれるリソース）をHTTPS経由で提供する必要があります。

1997年だったら、「はい」をクリックした場合、Internet Explorerは混合コンテンツの危険性を無視し、平文のHTTPを使用してサブリソースを読み込んでいました。そして、[いいえ] をクリックすると、読み込みを防止しました (多くの場合、破損しているけれども安全なWebページが表示されることになりました)。

完全に安全なコンテンツへの移行

混合コンテンツの解決策を「https://を使ってすべてを読み込み、Webサイトを修正するだけで」いいと簡単に考えることは、魅力的かもしれませんが、甘い考えです。残念ながら、ファーストパーティやサードパーティのWebサイトから最新のWebサイトに読み込まれた混合コンテンツの変更を「簡単に」行うことは非常に困難なのです。

Wiredはブログ投稿の中で、https://への移行について取り上げ、すべてをHTTPSに移行することがどれほど大変なことかを文書にまとめています。彼らは4月に開始し、5か月をそのプロセスに費やしました（メインWebサイトをhttps://にするのに、すでに何か月も費やした後の話です）。5月には、問題点に関する記事を投稿しています：

「[...] HTTPSへの移行における最大の課題の1つは、すべてのコンテンツを安全な接続で配信できるように準備することです。ページが HTTPS 経由で読み込まれる場合、他のすべてのアセット (画像やJavascriptファイルなど) も HTTPS 経由で読み込む必要があります。これらの「混在コンテンツ」の問題を報告する大量のレポートや、安全な HTTPS ページのコンテキストに安全ではないHTTPアセットが読み込まれるイベントを目にしています。適切に移行するには、混在したコンテンツの問題がより少なくなるように確認する必要があります。つまり、WIRED.comのコンテンツの多くをできる限り安全な状態で、配信できるようにする必要があるのです。

2014年に、ニューヨーク・タイムズは、混合コンテンツを安全化への大きな障害だと指摘しました。

「HTTPS に正常に移行するには、ページアセットへのすべてのリクエストを安全なチャネル経由で行う必要があります。これは困難な課題であり、可動部分がたくさんあります。JavaScriptから広告アセットまで、安全でないドメインから現在読み込まれているリソースを考慮しなければなりません。」

W3Cは、これを大きな問題として認識し、「中でも注目すべきなのは、混合コンテンツの確認は、大量のレガシーコンテンツをHTTPSに移行させるという作業を担当する管理者の頭を悩ませる可能性があることです。特に、古いコンテンツを確認して、リソースURLを手動で書き換えるという作業は、とても大変な作業です。」と述べています。そして、困難な例として、BBCの巨大アーカイブを引用しています。

しかし、混合コンテンツの問題を抱えているのは、メディアサイトだけではありません。CMSユーザーの多くは、CMSが生成するすべてのリンクを更新することは困難または不可能だと考えています。設定ファイル、ソースコード、またはデータベースにリンクが埋もれている可能性があるためです。さらに、ユーザーが生成したコンテンツを処理する必要があるサイトも、http://URI の問題に直面します。

混在コンテンツの危険性

混合コンテンツには、アクティブとパッシブの2種類があります。最新のWebブラウザがどのように危険性に対処するかというと、アクティブ混合コンテンツ（最も危険）は自動的に完全にブロックし、パッシブ混合コンテンツは許可しますが、警告を表示します。

アクティブコンテンツはDOM（Webページ自体）を変更できるものすべてを指します。リソースは <script>、 <link>、 <iframe>または <object> タグを経由して取り込まれ、CSSは、URLを使用するリソースを優先し、XMLHTTPリクエストを使用している全リクエストは、ページの変更、Cookieの読み取り、ユーザー資格情報へのアクセスが可能です。

パッシブコンテンツはそれ以外のものです：ページには組み込まれているけれども、それ自体でページにアクセスすることはできない画像、オーディオ、ビデオがこれにあたります。

アクティブコンテンツは本当の脅威になります。攻撃者が http://URI のリクエストを傍受した場合、コンテンツを独自のコンテンツに置き換えることができるためです。これは理論上の問題ではありません。2015年にGithubは、Great Cannonと呼ばれるシステムによって攻撃を受けました。Great Cannonは、HTTP経由で一般的なJavaScriptファイルのリクエストを傍受し、JavaScript攻撃スクリプトに置き換えました。TCPを傍受し、http://URI から読み込んだアクティブコンテンツに固有の脆弱性を悪用することで、罪のないユーザーのマシンを武器にしたのです。

パッシブコンテンツはタイプの異なる脅威です。パッシブコンテンツに対するリクエストは（暗号化されず）平文で送信されるため、傍受者はリクエストを監視し、情報を抽出することができます。たとえば、傍受者が適切な場所にいれば、Cookie、訪問先のWebページ、さらに、もしかすると認証情報も監視できるかもしれません。

Firesheep Firefoxアドオンは、ローカルネットワーク（例えば、コーヒーショップにあるネットワーク）で、リクエストがHTTPで送信されるのを監視し、自動的にCookieを盗み、誰かのIDをワンクリックで乗っ取ることができてしまいます。

現在、最新のブラウザでは、安全でない状態で読み込まれているアクティブコンテンツをブロックしますが、パッシブコンテンツは通過させてしまいます。やはり、すべてをhttps://へと移行することが、混在コンテンツに関するすべてのセキュリティ上の問題に対処する唯一の方法なのです。

混合コンテンツを自動的に修正する

当社ではWebを完全に暗号化することを目標として掲げているため、長い間、混合コンテンツを適切に修正したいと考えてきました。そして、他のCloudflareサービスと同様に、私たちはこれを「ワンクリック」で実現できる体験にしたいと考えました。

当社はいくつかのアプローチを検討しました。

the upgrade-insecure-requests CSPディレクティブを自動的に挿入する

upgrade-insecure-requestsディレクティブはContent Security Policyヘッダーに次のように追加されます。

Content-Security-Policy：upgrader-insecure-requests

これは、HTTPリクエストをHTTPSに自動的にアップグレードするようにブラウザに指示します。これは、Webサイトの所有者がすべてのサブリソースが HTTPS 経由で利用可能であることを知っている場合に便利です。Webサイトは実際にWebサイトに埋め込まれているhttp://URIをhttps: //に変更する必要はありません。ブラウザが自動的にこれを処理します。

しかしながら、upgrade-insecure-requestsには大きな欠点があります。ブラウザは、結果として得られるURIが実際にページで動作するかどうかなどはお構いなしで、ひたすらすべてのURIをhttps: //にアップグレードするので、ページが壊れる可能性があるのです。

https://を使うように全リンクを修正する

Cloudflare Webサイトの訪問者が使用するすべてのブラウザがupgrade-insecure-requestsをサポートしているわけではないため、Cloudflareでは当社サービスを使って、すべてのhttp://URIを https://にアップグレードすることを検討しました。Webページをリアルタイムで解析して変更することができるので、ブラウザのサポートに依存しない「upgrade-insecure-requests」サービスを作成することができました。

残念ながら、このサービスでも、http://URI をhttps://に変換すると、リンクが壊れるという同じ問題が起こりますが、実際にはHTTPSを使用してリソースを読み込むことはできません。

他のCloudflareサイトを指すリンクを修正する

Cloudflareでは、400万人のお客様に無料でUniversal SSLを提供しており、Webトラフィックの大部分をカバーしているため、http://からhttps//に当社が把握しているURIをアップグレードすることは、（URIが当社のサービスを使用しているので）できると考えていました。

これは問題の一部を解決しますが、HTTPからHTTPSへのアップグレードに関する一般的問題の解決にはなりません。

既知のHTTPS対応のURIを書き換えるシステムを作成する

最終的には、スマートな方法で解決することができました。リソースがHTTPSを使って提供できることがわかっている場合には、URIをhttp://からhttps://にアップグレードしました。どのリンクがアップグレード可能かを把握するために、EFFの優れたHTTPS Everywhere拡張機能とGoogle ChromeのHSTS Preloadリストを使用して、SSLが有効になっているCloudflareサイトに関する知識を強化しました。

EFFがこのプロジェクトを手伝ってくれたことにとても感謝しています。

HTTPS Everywhere ルールセットは、http://から https://への切り替えに加えて、非常に特殊なURIをターゲットにできるルール（および除外）が含まれています。たとえば、gstatic.comの実際のHTTP Everywhereルールは次のようになります。

    <rule from="^http://(csi|encrypted-tbn\d|fonts|g0|[\w-]+\.metric|ssl|t\d)\.
    gstatic\.com/" to="https://$1.gstatic.com/"/>

HTTPS Everywhereは、正規表現を使用して、HTTPSを使用するために安全にアップグレードできるgstatic.comのサブドメインを識別します。完全なルールのセットはこちらで参照できます。

Webページに埋め込まれた膨大な数のURIをアップグレードする必要があるため（毎秒500万前後になると見積もっています）、既存のHTMLパーサー（当社独自のものを含む）をベンチマークとし、このタイプの書き換えタスクのために新しいものを書くことにしました。今後のブログ記事では、その設計、テスト、パフォーマンスについての詳細を投稿する予定です。