Mozilla Security Blog 日本語版

Mozilla Security Blog を日本語に翻訳(非公式)

【翻訳】Mozilla Winter of Security-2015 MozDef: Virtual Reality Interface

この記事は、2016 年 2 月 5 日付で Mozilla Security Blog に投稿された Mozilla Winter of Security-2015 MozDef: Virtual Reality Interface(筆者: Jeff Bryner)の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

Mozilla では毎年 Winter of Security (MWoS) を開催しており、現在も開発が続けれらているセキュリティプロジェクトに対して、参加者の皆さんがコントリビュートするというイベントです。今年のグループは意欲的なテーマに取り組み、MozillaMozDef: The Mozilla Defense Platform と呼んでいる Elastic Search 用 SIEM オーバレイに、新しい視覚インターフェイスを構築 する ことがテーマとなりました(SIEM: Security Information Event Management)。

セキュリティ担当者には高いレベルの内容が要求されますし、アナリストのスキルセットもそのレベルを維持し続けるのは困難です。それゆえ私は、人々のセキュリティを向上させることに専念するのみならず、むしろセキュリティを人間の感覚に近づけることも必要だと固く信じています。今回のテーマ「分かりやすさと使いやすさを両立したインターフェイス」に投資する価値はあるでしょうし、このチームが制作した作品に私はとてもわくわくしています。

参加者の皆さんは、作品の素晴らしいデモンストレーションを発表してイベント全体を終えました。もしセキュリティの自動化ツールや代替のユーザインターフェイスに興味をお持ちになったら、air mozilla で彼らの成果をぜひご覧ください

【翻訳】中間者の介入とセキュリティの向上

この記事は、2016 年 1 月 6 日付で Mozilla Security Blog に投稿された Man-in-the-Middle Interfering with Increased Security(筆者: Richard Barnes)の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

2016 年 1 月 1 日から SHA-1 のサポートを廃止する(参考: 日本語訳)計画を以前にお知らせした通り、Firefox 43 からは SHA-1 によるダイジェストアルゴリズムで新規に署名された証明書を拒否するようになりました。新しく発行された証明書に SHA-1 が用いられているケースはそう多くないため、フィルタリングなしにインターネットへ接続しているユーザであれば、おそらくこの変更に気付かないでしょう。しかし、 "中間者" デバイス(セキュリティスキャナやアンチウイルスソフトを含む)の背後にいる Firefox ユーザは、この変更によって HTTPS の Web サイトへ接続できない場合があります。ユーザが HTTPS サイトに接続する際、中間者デバイスは Firefox に対して、サーバの真正な証明書の代わりに新しく作った SHA-1 の証明書を送信します。Firefox は新規の SHA-1 証明書を拒否するため、ユーザはサーバに接続することができません。

影響を受けているか調べるには

もし Firefox でこの記事(訳注: HTTPS でホストされている英語版の元記事)を閲覧できているのならば問題ありません。もし他のブラウザをお使いの場合は、Mozilla Security BlogFirefox で閲覧できるか確かめてみてください。もし表示できなかった場合、"Advanced" をクリック(訳注: Firefox 43 では「技術的詳細を表示」をクリック)して "SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED" というエラーコードが表示されているならば、お使いの Firefox は影響を受けています。

影響を受けていた場合に何をすべきか

最も簡単なのは最新版の Firefox をインストールすることです。ただし、Firefox の自動アップデートは HTTPS で行われているため、影響を受けていない Firefox のコピーや他のブラウザを使い、手動でインストールすることが必要となります。

再インストールを避けたい場合、操作に詳しいユーザは about:config で "security.pki.sha1_enforcement_level" の値を 0 に変更することで対処できます(この場合、すべての SHA-1 証明書を受け入れることになります)。

また、アンチウイルスソフトやセキュリティスキャナなどのように、通信路上で中間者の役割を担っている機器を最新にしておくべきでしょう。とあるベンダは、SHA-1 を使わないようにするための更新を最近配布しています。

SHA-1 の廃止を引き続き進めます

私たちは今なお、Firefox における SHA-1 証明書のサポート廃止を進めています。中間者デバイスの背後にいるユーザに更新が届くようにするため、また影響を受けている人数をより正確に把握できるようにするため、最新版の Firefoxでは SHA-1 証明書のサポートを再び有効にしています。TLS の中間者デバイスを製造するベンダの方は、製品が新しいダイジェストアルゴリズムを用いるように更新するべきでしょう。

【翻訳】Firefox における OCSP Stapling

この記事は、2013 年 7 月 29 日付で Mozilla Security Blog に投稿された OCSP Stapling in Firefox(筆者: David Keeler)の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

また、2015 年 3 月 3 日付の記事 Revoking Intermediate Certificates: Introducing OneCRL(参考: 日本語訳)ならびに 2015 年 11 月 23 日付の記事 Improving Revocation: OCSP Must-Staple and Short-lived Certificates(参考: 日本語訳)も合わせてご覧ください。


OCSP Stapling が最新の Firefox Nightly に実装されました!OCSP Stapling とは、プライバシーや拡張性を維持しながら、証明書の失効情報を Web サイトからブラウザへ伝達する仕組みです。

発行後の証明書が信頼できるかどうかは、その時点における失効情報によって決まるため、この情報はとても重要です。失効情報が重要となる例を挙げるのであれば、間違った情報を載せた証明書が認証局 (CA) から発行されてしまうかもしれません。Web サイトの管理者が秘密鍵を十分に管理できず、鍵が漏えいしてしまうかもしれません。そこまで攻撃的なものではなくとも、ドメインの管理者が変更されていたことに気付かないかもしれません。

こういった事故に備えるため、証明書の失効情報を得る方法の一つが Online Certificate Status Protocol (OCSP) です。証明書がブラウザに提示されると、その証明書に関する問題の有無を確認するため、ブラウザは発行元の CA に対して尋ねます。特に問題がなければ、証明書が有効だという宣言を CA が署名してブラウザに伝えることができます。もし証明書が失効していた場合、失効していることの宣言を CA は同じ仕組みで伝えることができます。

f:id:hashedhyphen:20151215223617p:plain

OCSP には欠点がいくつかあります。1 つ目は、新規に HTTPS コネクションを張る際の速度が落ちてしまう点です。新しい証明書を受けったブラウザは、該当する CA のサーバに追加のリクエストを行う必要があります。2 つ目は、ユーザがどの HTTPS サイトを訪問したか CA が分かってしまう点です。これはプライバシーの観点から問題です。さらに、ブラウザが CA に接続できなかった場合、何か問題があったとみなして接続を切断するか、接続を継続するかをブラウザが選択することになります。前者の場合は可用性を下げることになり、後者だと失効確認の意味がなくなってしまい、こうした選択を迫られるのは望ましくありません。現時点の Firefox では、この場合に接続を維持するようなデフォルト設定を採用しています。about:config において security.OCSP.require のオプションを true にすると、Firefox が CA に接続できなかった場合に接続を切断させるよう設定できます。

OCSP Stapling はこれらの問題を次のように解決します。まず、CA に対する証明書の失効確認作業を Web サイト自身から定期的に行わせて、CA が署名した宣言を Web サイト側が持つようにします。そして、新しい HTTPS コネクションの確立要求を受けた Web サイトは、事前に CA から取得していた宣言を最初のハンドシェイクに含めて送信します。ブラウザ側は、このハンドシェイクに添付された (stapled) 署名付きの宣言を取り出し、その宣言について検証を行い、その結果を元にして証明書の信頼性を判断します。もし信頼できないと判断した場合は、すなわち証明書に何かしらの問題が生じているため、ブラウザは接続を切断しなければなりません。何も問題が生じなければ証明書は有効であり、ユーザは Web サイトに接続することができます。

f:id:hashedhyphen:20151215223645p:plain

f:id:hashedhyphen:20151215223655p:plain

Firefox がリクエストをしたものの、宣言が添付された (stapled) レスポンスが返ってこなかった場合、Firefox は通常の OCSP と同じ手順にフォールバックします。つまり、誤った取扱いや多くの基本的な攻撃を防ぐのに OCSP Stapling は役立ちますが、より完全にネットワークが掌握された状態での攻撃までは防げません。例えば、OCSP には対応しているが OCSP Stapling は使用していない CA サーバがあったとき、ブラウザからその CA に向かう接続を攻撃者が遮ることが可能な場合、攻撃者が秘密鍵を盗んでいても失効情報がユーザに伝わることはありません。現在 "OCSP-must-staple" と呼ばれている新しい提案では、「このサイトへ接続する際は必ず、宣言が添付された OCSP レスポンスが含まれていなければならない」旨をWeb サイトがブラウザに指定できる方法を用意し、先程の問題を解決しようとしています。この機能はまだ開発途中です。

OCSP Stapling は、OCSP をサポートしている全 CA で利用可能であり、nginxApache を含む主要な Web サーバで実装されています。Web サイトを運営する際は、ユーザを保護するために OCSP Stapling を有効にすることを検討してください。もし Firefox Nightly のユーザであれば、セキュリティとプライバシー、そしてパフォーマンスが改善された環境をお楽しみください!