• 解決策と回避手段
  • 最も望ましい解決：HTTPSで接続するようにする
  • どうしてもHTTP接続しなければならない場合：安全でないダウンロードを遮断しないようにする
• 機能の導入の経緯と動作の変遷
  • 危険なダウンロードの遮断機能
  • HTTPS OnlyモードとHTTPS First
• 調査対応のポストモーテム
  • 実際の調査の流れ
  • 誤解とすれ違いを防ぐ
• まとめ

WebブラウザーのFirefoxには、ユーザー保護の一環として「安全でないダウンロードを積極的に遮断する」機能があります。 「安全でないダウンロード」とは具体的には、HTTPSで接続しているWebページからHTTPのURLで参照してファイルをダウンロードしようとした場合を指します¹。 通常の利用では安全性が高まって望ましい動作なのですが、法人運用で業務が依存しているWebサイト²がHTTPSではなくHTTPでの接続になっている場合、この機能の影響によってファイルのダウンロードができなくなり業務に支障をきたす場合があります。

この動作について、約1年前のFirefox 125（125.0.1）のリリースからしばらくの間、機能が強化されたり、緩和されたり、再度強化し直されたり、という不安定な状況が発生していました。 また、「特定のドメインでのみ安全でないダウンロードを許可する」ということもできず、機能を恒久的に無効化する以外の選択肢がないために、前述のような状況が発生した企業での運用には注意が必要でした。 その後、関係するポリシー設定がいくつか追加もされました。 こういった諸々の事があった結果、結局この機能は何だったのか、どうすれば制限を回避できるのか、ということが分かりにくくなってしまっています。

本記事では、お問い合わせに基づき当社で行った調査の範囲で、業務利用でこの機能の影響を受けないようにするための正しい解決あるいは回避の方法と、この機能が辿った変遷、および、それらを明らかにするまでに行った調査の過程とそこに見られた課題をご紹介します。

解決策と回避手段

最も望ましい解決：HTTPSで接続するようにする

この「安全でないダウンロードの遮断機能」が問題になるのは、運用コストなどの都合で自社ホストがHTTP接続のままとなっている場合がほとんどだと考えられます。

身も蓋もないのですが、本件の解決策としてまず取り組むべきなのは、それらのホストをHTTPS接続可能にするということです。 インターネット越しに利用するホストの場合は、Let's Encryptを使って商用・非商用を問わず無料でTLS用証明書を発行できるので、コストが理由でHTTPS非対応となっている場合は検討してみてください。

社内のローカルネットワーク内からのみ利用するホストや、関係者以外が利用する可能性がないホストの場合は、以下のようにして独自のルート証明書を使うことになります。

1. 自己署名証明書としてルート証明書を作成する。

2. 1のルート証明書から、TLS用のホスト証明書を当該ホスト用に作成する。

3. 2のTLS証明書を、当該ホストで使用するように設定する。

4. 1のルート証明書を、各端末のOSの証明書ストアに登録する。 Windows端末の場合は「エンタープライスの証明書」に登録する。

5. 4の証明書ストアを自動インポートするように、各端末のFirefoxにポリシー設定を適用する。 policies.json の場合は以下のように設定する。

   {
     "policies": {
       ...
       "Certificates": {
         "ImportEnterpriseRoots": true
       }
     }
   }
   

   GPOのポリシーテンプレートを使う場合は「管理用テンプレート」→「Firefox」→「Certificates」→「Import Enterprise Roots」を有効化する。

この対応を取れれば、基本的には、ダウンロード元となるページ（Webサービス）の修正対応は不要です。 これは、以下の理由のためです。

• 現行バージョンのFirefoxは初期設定で、「HTTPで接続するよう指示されても、まずはHTTPS接続を試行し、失敗したらHTTP接続にフォールバックする」動作となっています（HTTPS First）。 安全でないダウンロードの遮断は「HTTPSで閲覧中のページからHTTPで通信を行おうとする」場合で発動しますが、HTTPS Firstの動作により、このような場合は生じないことになります。
• すべての接続を必ずHTTPSで行う動作（HTTPS Onlyモード）に設定されている場合も、FirefoxはHTTP接続を指示されてもHTTPS接続を行うため、安全でないダウンロードの遮断機能の影響を受けなくなります。

言い換えると、HTTPS FirstとHTTPS Onlyモードのどちらも無効としている場合は、ダウンロード元ページで http:// で始まるURLで参照するよう指示されている物は、安全でないダウンロードとして遮断されることになります。 ダウンロードが遮断されないようにするためには、Webページを改修し、参照先のURLを https:// で始まる物になるよう修正する必要があります。

どうしてもHTTP接続しなければならない場合：安全でないダウンロードを遮断しないようにする

当該ホストを古いWebブラウザーや古いクライアントから利用する必要があるために、どうしてもHTTPSではなくHTTPで接続しなければならない、という場合には、まず安全でないダウンロードの遮断機能を無効化する必要があります。 少なくともFirefox ESR140およびそれ以前のバージョンにおいては、安全でないダウンロードの遮断機能には、特定のホストだけ遮断しないようにする例外の設定機能はないため、機能自体を無効化しなくてはなりません。 policies.json の場合は、Preferences ポリシーで以下の要領で設定します。

{
  "policies": {
    ...
    "Preferences": {
      ...
      "dom.block_download_insecure": {
        "Value": false,
        "Status": "locked"
      }
    }
  }
}

GPOの場合は、「管理用テンプレート」→「Firefox」→「Preferences」を有効化し、以下のようなJSONを値として設定します。

{
  ...
  "dom.block_download_insecure": {
    "Value": false,
    "Status": "locked"
  }
}

また、HTTPS Onlyモードでは当該ホストにHTTPではなくHTTPSで接続してしまい、HTTPでしか接続できないホストでは接続エラーとなるため、エラーを回避するためのHTTP接続を許可する例外サイトの設定も必要です。 これは、Firefoxの HttpAllowlist ポリシーを使用して以下の要領でURLのオリジン部分を設定します。

{
  "policies": {
    ...
    "HttpAllowlist": [
      "http://uploader.example.com",
      "http://example.example.net",
      "http://192.168.10.100/"
    ]
  }
}

こちらはGPOの場合は、「管理用テンプレート」→「Firefox」→「HTTP Allowlist」を有効化し、値のリストにホストのURL（のオリジン部分）を登録することになります。 HttpAllowlist ポリシーではURLは名前解決前に照合されるため、当該ホストをホスト名とIPアドレスの両方で参照する可能性がある場合は、先の例のようにホスト名のURLとIPアドレスのURLの両方を例外に登録する必要があります。

この「安全でないダウンロードの遮断機能の無効化」と「HTTP接続の許可リスト」という2つの設定は、HTTPS FirstもしくはHTTPS Onlyモードが有効な場合は片方だけの設定では不充分で、必ず両方とも設定しなくてはならないことに注意して下さい。 「HTTP接続の許可リスト」は安全でないダウンロードの遮断機能の例外リストとしては作用しないため、HTTP接続しか受け付けないホストを使用する場合には、安全でないダウンロードの遮断機能そのものを完全に無効化する必要があります。

機能の導入の経緯と動作の変遷

危険なダウンロードの遮断機能

Firefoxの「安全でないダウンロードの遮断機能」は、元々、mixed content³の取り扱いと同じ基準をファイルのダウンロードにも当てはめる形で、Firefox 80を対象に実装されました。 ただ、この時点では開発版でのみ機能が有効で、通常リリース版では無効とされていました。 その後、機能の安全性・安定性が確認されたためか、Firefox 93で一般ユーザーに対しても機能が有効化されました。 このことはリリースノートでも Firefox now blocks downloads that rely on insecure connections, protecting against potentially malicious or unsafe downloads. Learn more and see where to find downloads in Firefox. とアナウンスされています。

その後、Firefox 125⁴でこの機能の動作範囲が拡大され、リンク元ページとの関係がmixed content相当の場合かどうかの判断を行わず、URLがHTTP接続であるダウンロードは無差別に遮断するようになりました。 Firefox 125.0.1のリリースノートにおける Firefox now more proactively blocks downloads from URLs that are considered to be potentially untrustworthy. という記述は、この事を指しています。

しかしながら、それから間を置かず、この変更がHTTPで接続中のページからHTTP接続でファイルをダウンロードしたときにファイルが意図せず破損するという後退バグを引き起こしていたことが報告されました。 一般ユーザーへの影響が大きい問題だと判断されたためか、このときはFirefox Studies⁵を通じて dom.block_download_insecure の値が強制的に false に変更されました。

その後、問題を引き起こしていた変更、つまりFirefox 125.0.1で行われた「URLがHTTP接続であるダウンロードを無差別に遮断する」 動作のための変更が撤回され、Firefox 125.0.2がリリースされました。 この時点でFirefox Studiesを使った緊急措置も終了し、各クライアント上で dom.block_download_insecure の値は再び true の状態に戻されました。 それ以後、「URLがHTTP接続であるダウンロードを無差別に遮断する」 動作のための変更は保留のままとなっており、本稿執筆時点（Firefox 142時点）においても再導入はされないままとなっています。 ただ、変更案が完全に破棄されたわけではないため、今後どこかのバージョンにおいて、再度この変更が導入される可能性は否定できません。

HTTPS OnlyモードとHTTPS First

他方、FirefoxのHTTPS OnlyモードとHTTPS Firstは、世間の「常時HTTPS化」の流れを承けた機能と言えます。

Webが誕生した当初は、PC自体の性能が低く、社会におけるWeb依存度も低かったため、Webの通信は基本的には暗号化されず、通信相手も相手の自己申告頼みとなる、HTTPでの通信が主流でした。 しかし商取引をする上では、さすがに個人情報や決済情報を平文のまま公開のネットワークに載せるのは危険すぎますし、そもそも、通信相手が有名企業を騙る詐欺犯であっても困ります。 そのため、当時WebブラウザーとWebサーバーの両方を製品として展開していたNetscape Communications社はSSL⁶という技術を開発し、VeriSignなどの認証局事業者と提携して、「認証局がWebサイトの運営者に対して証明書を発行し、その証明書を用いて、WebブラウザーとWebサーバー間で通信相手の確認と暗号化による安全な通信を行う」方式であるHTTPSを広く一般に普及させました。

その後、Webの利用者の急増により社会がより強くWebに依存するようになったことで、いわゆるフィッシング詐欺が横行するなど、HTTPベースでのWebの安全性の低さが無視できないものとなってきます。 そこでEFF⁷やTor Projectは「HTTPS Everywhere」を提唱し、それまでの「特別に安全さが要求される商取引などの場面でのみHTTPSを使い、それ以外はHTTPが当たり前」という社会の風潮を「常にHTTPSを使うのが当たり前（常時HTTPS、あるいは常時SSL）」に改めることを促しました。 GoogleがHTTPよりもHTTPSで接続できるWebサイトの方を検索結果で優遇するようになったり、それまでは高額な手数料が障害となって証明書を購入できずHTTPS対応を行えずにいた小規模事業者や個人のWebサイト運営者向けに無償で証明書を発行する認証局「Let's Encrypt」が立ち上げられたりして、「常時HTTPS」での運用は、現代のWebサイト運営者側には一般化しつつあります。

しかしながら、常時HTTPS化が広まる前に作られて以後メンテナンスされていない古いコンテンツなどにおいては、リンク先のWebサイトが実際にはすでにHTTPSでの接続に対応していても、リンク元からの参照が http:// で始まる古いURLのままとなっている場合があります。 このような場合にもなるべく安全な通信を行うために、「可能ならHTTPSでの接続をまず試みて、駄目ならHTTP接続にフォールバックする」のが「HTTPS First」で、あるいはよりラディカルな対応として「必ずHTTPSでの接続を試みて、駄目なら通信失敗とみなす」のが「HTTPS Onlyモード」です。 これらのモードは、もはや更新されることが期待できない古いコンテンツを閲覧する際の安全性を、ブラウザー側で積極的に高めるものと言えるでしょう。

このように、「安全でないダウンロードの遮断機能」と「HTTPS Only/HTTPS First」は、同じ領域を対象にしていつつも、それぞれまったく別々の出自で搭載された機能となっています。 経緯を辿ると、HttpAllowlist ポリシーが「安全でないダウンロードの遮断機能」に影響しそうで影響しない理由を納得しやすいのではないでしょうか。

調査対応のポストモーテム

以上のように情報を整理するに至るまでにあたって、実は、当社担当者・お客様・Mozillaの開発者といった関係者の間で、先入観や情報の共有不足に基づく誤解やすれ違いがいくつも発生していました。 本記事の後半では、実際に行った調査の経緯をご紹介しながら、どこで誤解が生じていたのかを考え、誤解の少ないコミュニケーションを行うためのヒントを得てみたいと思います。

実際の調査の流れ

この調査は元々は、お客様からの以下のようなお問い合わせに端を発していました。

• Firefox 125.0.1で一部のファイルのダウンロード操作が遮断されるようになり、125.0.2で遮断されない状態に戻った。
• これはFirefox 125.0.1でHTTPでのダウンロードでファイルが破損するようになった問題に関係していたらしい。
• 当該記事では、現象が発生していたときの暫定的な回避策として、隠し設定の dom.block_download_insecure を変更する方法が案内されていた。
• この設定をポリシーで管理するにあたり、JSON文字列を手書きで編集しなくてはならない Preferences ポリシーを使うのは、システム管理担当者にとって負担が大きい。当該設定をこのポリシー以外で簡単に制御する方法はないか？

このお問い合わせを承けて調査した結果、当該設定を簡単に管理できるようなポリシー設定項目は存在しなかったことから、Mozilla公式のサポート情報サイトにあった、Firefox 125.0.1におけるHTTPでのファイルのダウンロードで発生する問題の記事を参照して、dom.block_download_insecure を簡単に制御できるポリシー設定を追加する提案を当社で行いました。 そこで「例外設定のためのポリシー設定が実装されようとしている」という情報を得られ、さらに、それが HttpAllowlist ポリシーであると分かったことから、お客様へ「dom.block_download_insecure を簡単に制御するポリシー設定は実装してもらえなさそうなものの、代わりに HttpAllowlist ポリシーが使えそうだ」という旨のことを一旦は回答しました。

そしてお客様から、HttpAllowlist の設定項目に *.example.com のようなワイルドカード指定が使えるのかどうかについて再度お問い合わせを頂き、当該ポリシー設定の実装の詳細を調査しました。 その結果、このポリシー設定ではワイルドカードは使えず、具体的なホスト名を含む http://uploader.example.com のようなURLのオリジン部分の文字列を記載する必要があることが分かった……のですが、それと同時に、このポリシー設定が影響するのはHTTPS First⁸とHTTPS Onlyモードに関する動作のみで、安全でないダウンロードの遮断機能（dom.block_download_insecure）とはどうやら関係が薄いようであるということも明らかになってきました。

そこで、先の「HttpAllowlist ポリシーが回避策として使えそうだ」という回答自体の妥当性を再検証するため、改めてそれぞれの機能の実装の詳細な経緯を調査することにしました。

1. まず、「導入された新機能で不具合が起こるようになった」という情報をヒントに、HTTPでのダウンロードで不具合が起こるようなったバージョンであるFirefox 125.0.1のリリースノートを閲覧し、何か情報が無いかを調べました。
   • リリースノートにそれらしい記載はあるものの、詳細は不明でした。
2. 1の詳細を知るために、リリースノートのページ最下部にある「Complete list of changes for this release」というリンクから、このバージョンで行われた全変更のBugの一覧 を閲覧しました。
3. Bug一覧には各Bugの要約として報告者が記入した内容が表示されているため、ここで「download」や「insecure」などの単語を含む項目があるかどうかをページ内検索で確認しました。
   • ページ内検索では、該当する項目は見付かりませんでした。
4. 調査範囲を拡大し、HTTPでのダウンロードの問題が修正されたバージョンであるFirefox 125.0.2のリリースノートを閲覧して、何か情報が無いかを調べました。
   • 該当する項目からは、HTTPでのダウンロードでファイルが破損する問題の報告（Bug 1892069）が関連情報として紹介されていました。
5. 当該Bugのページを開き、行われていた議論の経緯を把握するためコメントのやり取りを読みました。
   • 12番目のコメントを読み、Firefox Studiesでとりあえずのhotfixが行われていたという事実と、原因はHTTPでの通信を全面的に遮断する変更（Bug 1877195）で導入されたパッチにあり、パッチがバックアウトされて問題が解決したことを把握しました。
6. HTTPでの通信を全面的に遮断する変更の議論（Bug 1877195）を閲覧し、バックアウトされたパッチで何が行われていたか（何が問題を引き起こしていたのか）を調べました。
   • 全体的には自動テスト（パスやファイル名に test が含まれるリソース）の追加がほとんどであった中に、C++での実装の変更が含まれていたことが分かりました。
     • パッチの詳細を確認し、dom.block_download_insecure 有効時の処理に関わる部分にも変更が行われていたことが分かりました。
     • この時点で、「パッチがバックアウトされて、Firefox 125.0.1で起こるようになった『HTTPでのダウンロードが遮断される』状況は解消された」「しかしまたこの機能が入る余地は残っており、その時は『HTTPでのダウンロードが遮断される』状況が再発するかもしれない」ということが分かりました。

ここまでの調査で得られた情報を整理した結果が、本記事の前半となります。

誤解とすれ違いを防ぐ

この調査の流れを注意深く見ると、「お客様とクリアコードの担当者（以下、我々）」と「Mozillaの開発者や参照先のサポート情報（以下、Mozilla側）」では関心の領域がズレていることが分かります。

• 我々は、HTTPでのダウンロードが遮断されてしまうことを問題視し、ダウンロードが遮断されないようにすることに関心を持っていた。
  • dom.block_download_insecure の設定変更は、そのための有効な回避策であったが、設定の反映の仕方が煩雑であることがネックであった。
• Mozilla側は、HTTPでのダウンロードの遮断を推進しており、その機能の影響でファイルが意図せず破損してしまうことを問題視し、ファイルが破損しないようにすることに関心を持っていた。
  • dom.block_download_insecure の設定変更は、問題を回避するための暫定的な方法として有効ではあったが、本質的な解決ではなかった。そのため本質的な解決として、一度は反映された変更の取り消しと、別途例外設定の実装を進めていた。

両者いずれも、共通の話題として dom.block_download_insecure という隠し設定が登場します。 我々は「この隠し設定を簡単に制御したい」ということだけを記載してポリシー設定の新設を提案したのですが、この時点でMozilla側には、提案の背景のうち、我々の主たる関心事だった「HTTPでのダウンロードが遮断されないようにもしたい」という部分が伝わらず、Mozilla側でも認知していた「HTTPでのダウンロードでファイルが破損しないようにしたい」という意図だけでの提案だと誤認されてしまったようでした。 そのため、得られた回答は「ファイルが意図せず破損してしまう問題は修正されるので、ポリシー設定の新設は予定していない」というものでした。 その上で、Mozilla側は関連情報として「HTTPS強制の例外を設定するポリシーを実装しようとしている」という情報を提供してくれたのですが、我々はその情報の文脈を読み誤って、「（ファイル破損を防ぐ以外に、HTTPでのダウンロードが遮断されないようにする方法としても有効な）HTTPS強制の例外を設定するポリシーを実装しようとしている」と受け取ってしまいました。 第1の落ち度は、この食い違いに（双方が）気付けなかった点です。

それでも、この時点で、「例外設定のポリシー（HttpAllowlist）がHTTPでのダウンロードが遮断されないようにするための例外設定として機能するのかどうか」の裏付け調査を行っていればよかったのですが、この時は裏付け調査を行わないまま、（誤解に基づいて）事実と異なる情報を回答してしまっていました。 その後、当社内で別の担当者が、お客様からの追加の質問に回答するためにそれまでの経緯を改めて読み込んだ際に、そのような裏付け調査がなされていなかったことに気が付き、詳細な調査を行った結果、当該設定は我々が求めていたものではなかったことがようやく明らかになったのでした。 第2の落ち度は、この裏付け調査をすぐに実施できなかったにも関わらず、不確定な情報を確定情報のように回答してしまった点です。

このようなすれ違いを防ぐための方策には、どういうものがあるでしょうか。 筆者は以下のように考えています。

• アップストリームに要望や質問を投げる際は、こちらが持つ背景事情を省略せずに説明する。断片的な説明にならないようにする。
• 得られた情報について、きちんと裏付け調査を行う。裏付け調査を完全には行えない（その時間的猶予がない）場合は、その時点での確定情報と不確定情報を分けて依頼者に伝える。

アップストリームへ報告を行うとき、「余計な情報を入れるとノイズになるのではないか」と考えて情報を削りすぎてしまうことはよくあります。 その結果誤解が生じることを考えると、報告に含める情報は増やした方がよいのですが、とはいえ無秩序に説明を増やすと、「説明が長すぎて何を言っているか分からない」と受け取られてしまうリスクも生じます。 そのようなリスクを減らしつつ適切な情報を伝えるため、障害報告を行う場面では「情報を詳しく、ただし、整理して伝える」ということが重要です。 今回の事例では「知りたいこと」はすでによくまとまっていたので、それと分けて「背景情報の説明」を足せば、詳細さと分かりやすさを両立できそうです。

また、自分が誰かの代理として動いている場面では、得られた情報をなるべく早く依頼主に伝えたいものですし、その際は、確定的に言い切りたくなるものです。 ですが、「できるか、できないか」について事実確認ができていない時点で「できる」と伝えてしまうと、それを前提にして後工程まで動き出し始めてしまい、ともすれば、後々「できない」と分かったときの影響が甚大なものとなり得ます。 そうなると結局の所、一番困るのは依頼者です。 このような場面では、できれば勇気を持って「まだ判断はできません、さらなる調査が必要です」と事実を誠実に伝え、依頼者の理解を得た上で着実に調査を進めていくようにしたいものです。

まとめ

以上、Firefox 125のリリース前後で発生していたHTTPでのファイルのダウンロードに関するいくつかの混乱について、関係する機能の概要と回避方法、ならびに、それらの情報を明らかにするまでの調査過程で見られた課題をご紹介しました。

Firefoxのようなオープンソースの製品は、トラブルが起こった際に原因究明をとことん行えるのが利点の一つですが、その反面、困難な問題や複雑な問題では、調査自体にノウハウが必要だったり、求めていた情報を得るまでの調査に時間がかかったりすることがしばしばあります。

株式会社クリアコードは、お客さまからのお問い合わせに基づいて、オープンソース製品のソースコードまでも対象にした調査や、トラブルの解決方法のご提案などを行うサポートを、有償にてご提供しています。 オープンソース製品の運用でお困りの企業のシステム管理・運用ご担当者さや、関連ソフトウェアの開発でお困りのことがある開発チームのリーダーの方は、是非ともお問い合わせフォームよりご連絡下さい。

ツイートする

フォローする