HTTP でスクリプトを読み込む HTTPS ページは、異なる二つの保護水準で二つのリクエストを行い、南京錠が示すのは最初の一つだけである。トンネルはこれを変えない。トンネルが守るのは運搬経路であり、リソース自身のスキームではないからだ。アドレスバーではなくコンソールを読めば、どのリクエストが失敗したかはブラウザがすでに教えてくれている。三つの確認で、半分しか動かないページから実際の修理へと進める。

アドレスバーではなくリクエストを読む

HTTPS で取得した文書は、平文の HTTP 経由でスクリプト、スタイルシート、フォント、フレームを参照できる。その参照は別個のリクエストであり、ブラウザが不平を言うのはそちらである。本文書の保護はそこへ遡って及ぶことはなく、二つの流れを運ぶトンネルもどちらのスキームも変えない。したがってページは、本当に安全でありながら本当に壊れている、という状態になり得る。

リソースを単なるインクルードファイルと呼んでも、差し替えることが無害になるわけではない。

安全でないスクリプトの中身が途中で改変され、そのまま実行され得るなら、ページの挙動を変えられる。これは見た目の不具合より大きな問題である。画像は途中で改変されると、より小さいが現実のリスクを負う。南京錠は何についても嘘をついていない。答えているのは、あなたが尋ねた問いより狭い問いである。

どのリソースがブロックされ、どれが昇格されるかを知る

ブラウザはすべての種類のリソースを同じようには扱わない。 混合コンテンツに関するガイダンス は、HTTPS へ昇格されるリクエストと完全にブロックされるリクエストを区別し、スクリプト、スタイルシート、プログラムによるリクエストはブロックされる側に、画像とメディアは代わりに昇格または警告の対象になり得る。

この違いが、紛らわしい報告を説明する。スクリプトがブロックされたページは機能を完全に失うが、画像が昇格されたページは問題なく見え、静かにリクエストを変えている。文書化された分類には例外もあるため、ある種の URL が必ず昇格に成功するとは考えないこと。ファイル拡張子から推論するのではなく、コンソールがその特定のリクエストについて何と言っているかを読む。

ウィジェットがブロックされたことは、トンネルが失敗した証拠ではない。ブラウザが仕事を果たした証拠である。

参照をその発生源で直す

サイトの所有者にとって、修理は安全でない URL が書かれた場所に属する。テンプレート、スタイルシート、URL を組み立てるスクリプト、あるいは第三者のコンポーネントである。表示されるページのアドレスを変えても、それらは手つかずのままである。ソース内でホストを検索し、コンソールがたまたま名指しした一つだけでなく、すべての参照を直す。

次に、そのリソースが本当に有効な身元を伴って HTTPS で配信されているかを確認する。スキームを差し替えても、そこに一度も公開されなかったサービスを出現させることはできない。

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

リダイレクトも追うこと。HTTPS で始まる参照でも、平文の配信経路に着地することがある。依存関係に安全な配信がまったくない場合は、回避策を出荷するのではなく、通常の変更手順で削除または置換する。利用者に対しては、ブラウザの保護を有効なままにし、リソースの URL、種類、コンソールのメッセージをサイトの所有者に報告する。一つのページのために従業員に安全でないコンテンツを許可させる指示を広めてはならない。その例外は、それを引き起こした事故より長く生き残るからだ。

利用者が触れるやり方でページを再テストする

最初の文書だけでなく、必要に応じてリソースを読み込む操作も試す。ページはボタン操作の後に追加のコード、データ、ダウンロードを取得し、それらのリクエストが安全でないこともしばしばである。保護を有効にしたまま、具体的なリクエストと目に見える挙動を確認する。緩めたブラウザプロファイルから始めるテストでは、通常の利用者が見るものは分からない。

トンネルには依然として独自の役割があり、その役割はネットワークアクセスであって、ページの完全性ではない。

トラフィックがトンネルの終端を離れた後も、残っている HTTP 取得が運搬経路から得たものは何もない。リソースの経路を直し、ブラウザ側の強制はそのままにしておく。安全でない依存関係の修理としてさらに一段のトランスポート層を扱うのは、正しく機能していた制御を無効にするヘルプデスク用スクリプトに、チームが行き着く道である。

関連記事