Mozilla Security Blog 日本語版

Mozilla Security Blog を日本語に翻訳（非公式）

【翻訳】March 2016 CA Communication

この記事は、2016 年 3 月 29 日付で Mozilla Security Blog に投稿された March 2016 CA Communication（筆者: kwilson）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

私たちは Mozilla 製のプログラムに登録されている ルート証明書の 認証局（CA） に Communication を通知しました。Mozilla's CA Certificate Program では、ルート証明書を Network Security Services (NSS) に登録する手続きを管理しています（ちなみに NSS とは、セキュリティを確保したクライアント・サーバアプリケーションをクロスプラットフォームで開発できるよう設計された、オープンソースのライブラリ群です）。NSS に登録されたルート証明書を利用するのは、Firefox ブラウザといった Mozilla のプロダクトのみならず、他の企業やオープンソースプロジェクトの様々なアプリケーションでも用いられています。

CA Communication は、Mozilla 製のプログラムに関係する各 CA の Primary Point of Contact (POC) である担当者宛にメールで送信されました。ここでは以下の 7 項目のアクションにお答えいただくようお願いしています。

  1. 証明書の署名アルゴリズムから SHA-1 を廃止する（参考: 日本語訳）作業の進展を報告すること

  2. 中間証明書のデータ を Salesforce 上の CA Community に記載すること

  3. 失効した中間証明書のデータ を Salesforce 上の CA Community に記載すること

  4. mozilla::pkix から回避策を削除するため、このリスト に載っている問題を抱えた証明書を発行しないこと

  5. 期限切れや顧客の移動を目的としたルート証明書の削除予定を報告すること

  6. テスト用の証明書を含むすべての証明書について、これらが Mozilla の宣言しているポリシー に準拠しなければならないことの確認

  7. ルート証明書における所有権の移管手続きに関する変更点を、Mozilla の Root Transfer Policy に従って報告すること

アクション項目の全文は こちら から参照できます。この調査に対する返答は Salesforce によって 自動かつ速やかに公開されます。

私たちがこの CA Communication を行うのは、Mozilla's CA Certificate Program への参加は Mozilla が決定権を有していること、私たちのユーザの安全を確保するために必要な手段はすべて講じることを強調するためです。しかしそれでも、安全を確保するベストな方法は、パートナーである CA と協力すること、オープンで実直な意思疎通を促すこと、そしてより良い改善策を誠実に探し続けることだと信じています。

【翻訳】強度の弱い暗号をまだ利用している支払いサービス事業者

この記事は、2016 年 2 月 24 日付で Mozilla Security Blog に投稿された Payment Processors Still Using Weak Crypto（筆者: Richard Barnes）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

Web を保護する活動の一環として、Mozilla は Web PKI のガバナンスに参加しています。Web PKI とは、ブラウザが Web サイトを認証できるようにするセキュリティ証明書の仕組みです。Mozilla は 他のブラウザや Web におけるステークホルダー とともに、証明書の発行手続に関する 標準 に同意します。これから私たちはこの標準を適用し、加えて Mozilla 独自のポリシー も追加します。このポリシーは Firefox が信頼する「ルート」から（直接・間接にかかわらず）発行された証明書すべてに適用されます。

パブリックなインターネット上で支払情報を交換する支払いサービス事業者の中には、サーバと支払端末の間に安全な通信路を確保するために Web PKI 証明書（Firefox の信頼するルートまでチェインがつながっている証明書など）を利用していることがあり、これまで私たちはこのような事業者を紹介してきました。残念ながら、ブラウザ以外の Web PKI ユーザの中には、Web の獲得したセキュリティの向上に追いつけていないものがあります。（証明書の完全性を確認するために用いる）SHA-1 ハッシュアルゴリズムは、Web PKI における利用を廃止することが宣言されましたが、そのような事業者はデバイスを更新できておらず、代替の SHA-2 がサポートされていません。なお、SHA-1 の利用期限は昨年に決定されたものです。この結果、支払サービスに関係する多くのデバイスは、サービスを運用させるために SHA-1 の証明書をサーバに要求し続けています。

特に Worldpay PLC の場合、自身が利用する認証局の Symantec を通じて、限られた数の SHA-1 証明書を発行する権限の認可を Mozilla に要請しました。この証明書は多くの古いデバイスをサポートするために必要ですが、Mozilla の同意する標準に違反しています。また、この要請があったのは、認可を必要とする日まで 2 週間を切っているタイミングでした。dev.security.policy のメーリングリストで議論 を重ねた結果、これらのデバイスを利用するユーザの混乱を防ぐため、証明書の発行を例外的に 許可 するよう決定しました。ただし、SHA-1 証明書の発行に完全な透明性を確保し、SHA-2 への移行を目的としていることを条件としました。

この認可により、Worldpay のデバイスを長く運用させるため SHA-1 証明書が Symantec から発行できるようになり、Mozilla はその証明書発行を欠陥と扱わなくなります。この決定は Mozilla のルートプログラムのみに影響を与えるため、他のルートプログラムでは誤った証明書発行と扱われる可能性があります。

Web PKI を利用するしないにかかわらず、Worldpay の他にも同じく SHA-1 を必要とし続ける支払いサービス事業者がいることは把握しています。こういった団体が強度の弱い時代遅れのセキュリティ技術を利用することで、一般市民のデータがリスクにさらされてしまうのは残念でなりません。Web PKI で SHA-1 を必要とし続ける団体には、可能な限り状況が改善されるよう働きかけを行い、SHA-2 への移行策をできるだけ詳しく提供していきます。

【翻訳】現実の Web に向けた CSP

この記事は、2014 年 10 月 4 日付で Mozilla Security Blog に投稿された CSP for the web we have（筆者: Mark Goodwin）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

イントロダクション

Content Security Policy (CSP) は、クロスサイトスクリプティング（XSS）を防ぐセーフティネットに適したものです。実際、CSP はとても良く作られており、新しい Web サイトの構築時には CSP をぜひ導入してほしいと思います。

CSP を導入するとデフォルトの制約がいくつか適用されるため、既存の Web サイトに CSP を導入するのは難しい場合があります。また、このような制約を考慮せずにコードが書かれていた場合でも、導入には労力が必要となってしまいます。これらの問題に対する回避策は確かに存在しますが、ポリシーを適用して得られる利益が回避策によって損なわれてしまい、本末転倒になりかねません。とりわけ、インラインスクリプトには注意が必要です。インラインスクリプトはよく使われていますが、もしポリシーでそれを許可してしまうと、もはや CSP の主な利益を享受することはできません。これまで CSP を効果的に利用するには、コードを書き直して既存のインラインスクリプト・スタイルを削除するしかありませんでした。

CSP を既存の Web サイトに適用する労力に最初は驚くかもしれませんが、その労力に見合うほどの利益をセキュリティに得ることができます。幸いにも、CSP 2 では既存サイトへの導入が容易になりました。

CSP 2 の機能

CSP 2 では hash-source と nonce-source という、本当に便利な機能が提供されています。これらの機能を用いると、コンテンツを差し込む隙を攻撃者に与えることなく、インラインのスクリプト・スタイルを使用できるようになります。

それではまず nonce-source の動作を確認してみましょう。

nonce-source を用いた CSP は次のような形をとります。

content-security-policy: default-src 'self'; script-src 'nonce-2726c7f26c'

そして対応するドキュメントには以下の script 要素が含まれています。

<script nonce="2726c7f26c">
alert(123);
</script>

ここで注意すべきことが 2 つあります。1 つ目はレスポンスごとに nonce の値を変えることが重要だということ（先程の例では値が変わりません！）、2 つ目は nonce に対する予測困難性が重要だということです。

nonce は予測できない方法で変更されるため、攻撃者はどの値を nonce に入れればよいか分かりません。そのため、正しい nonce を持った script (style) 要素だけを許可することができ、コンテンツが差し込まれていないことを保障できるのです。

さて hash-source はどうでしょうか？先程と同様に、ドキュメント内の script 要素や style 要素が、CSP に指定された source と一貫性を持っていることが保障されます。しかし、動作の仕組みは異なります。hash-source の場合はドキュメント内の script 要素に属性値を指定せずに、許可したい script 要素のハッシュ値を計算し、その値を CSP の中に指定します。

従って次のような script 要素の場合、

<script>
alert(123);
</script>

hash-source を用いた CSP は次のような形をとります。

content-security-policy: script-src 'sha256-cLuU6nVzrYJlo7rUa6TMmz3nylPFrPQrEUpOHllb5ic='

すぐ分かるように、ドキュメントに含めたいスクリプト・スタイルのそれぞれについて hash-source を追加する必要があります。

どちらを使うべきか（そして使うタイミング）

ここで、なぜ 2 つの仕組みがあるのか（インラインのスクリプト・スタイルを許可するに際して、どのような場合を意図して設計されているのか）疑問に思うかもしれません。どちらを使えばよいのか悩むかもしれません。実際、これらのテクニックはインラインスクリプトを取り除くことができないケースのみを意図しているため、どんな場合でもこの仕組みを使おうとするのは避けるべきです。

nonce-source はシンプルなため、ほとんどの場合で nonce-source のほうが便利でしょう。インライン要素が数多く存在する場合でも、ポリシーに追加する source は 1 つだけで十分です。反対に欠点としては、nonce は一度だけしか使ってはいけないため、ページがロードされるたびに新しいヘッダ（と新しいドキュメント）を生成する必要があります。従って、動的に生成されるページに nonce-source は適していますが、静的なコンテンツには全く適していません。

hash-source はより複雑です。許可したいすべての要素ごとにハッシュ値を計算する必要があり… とはいえ、ハッシュ値は攻撃者に知られても問題ないため、毎回 CSP と script 要素に変更を加える必要がありません。従って、hash-source は静的なコンテンツを保護するのに役立つ仕組みといえます。

利用上の注意

これらの機能を動的に生成されたコンテンツに用いる際は気を付けてください。なぜなら、nonce 属性を設定した（または hash-source を計算する元となった）要素内に攻撃者がコンテンツを差し込めた場合、攻撃者はどのような制限も回避できてしまうからです。

機能上の制約

CSP によるインラインスクリプトの制限は、スクリプトを値にとる属性（DOM Level 0 イベントハンドラで通常用いられる onclick など）も含まれ、hash-source と nonce-source はこれらに対応できません。現在の CSP では属性値のスクリプトにディレクティブを適用できませんが、今後の動向に注目しましょう！