セキュリティアドバイザリー

概要

2016年10月13日午前11時10分 (GMT) 頃、Fastly でホストされている一部の証明書を含む、GlobalSign の TLS 証明書を使用する Web サイトにアクセスするユーザーに、TLS 証明書の検証エラーが発生し始めました。この問題は、Fastly のパートナーである証明書認証局の GlobalSign によって発行された証明書失効情報が正しくないことが原因で発生しました。

このセキュリティアドバイザリでは、この問題の根本原因と、お客様への影響を制限するために Fastly が実施した対応についてご説明します。

影響

GlobalSign が発行する証明書を使用する特定の Web サイトにアクセスしたユーザーに対し、「NET::ERR_CERT_REVOKED」などの証明書の検証エラーが表示された可能性がありました。

Fastly が提供する TLS オプションによっては、Fastly の TLS 証明書認証局である GlobalSign から Fastly がお客様のために調達する証明書を使用する場合があります。これらのオプションをご利用いただいているお客様はこのインシデントの影響を受けました。たとえば、Fastly の共有証明書は、自動的に GlobalSign を通じて発行された証明書を使用します。GlobalSign 以外のベンダーによって発行された証明書を Fastly の証明書ホスティングまたは SNI 証明書ホスティングで使用しているお客様は、この問題の影響を受けませんでした。

エラーには一貫性がなく、正しくない OCSP 応答を受信した少数のユーザーにのみ影響していたと考えられます。この問題は、ローカルマシンが OCSP エントリをキャッシュした場合に、最大で4日間存続していた可能性があります。Fastly がインシデント発生時のトラフィックレベルを再確認したところ、お客様全体のトラフィックに顕著な減少は見られませんでした。

詳細

根本原因

2016年10月7日頃、認証局 GlobalSign はクロス証明書を削除し、この失効を含む証明書失効リスト (CRL) を発行しました。2016年10月13日より、GlobalSign 側で Online Certificate Status Protocol (OCSP) のレスポンスのコンパイル時に技術的なエラーが発生し、同社の OCSP レスポンダーにより、多数の中間証明書について正しいレスポンスが返されないという状況が生じました。これにより、GlobalSign によって発行された複数の中間証明書が失効していたと一部のブラウザが推測する結果を招きました。

この情報は、GlobalSign の Online Certificate Status Protocol (OCSP) レスポンダーを通じて伝播され、一部のケースでは Fastly 以外の中間の CDN やクライアントシステム上でキャッシュされました。

この正しくない OCSP レスポンスの結果、Fastly によってホストされている多数のサービスを含む、GlobalSign の証明書を利用している Web サイトにアクセスした一部の Web ユーザーに証明書の検証エラーが発生しました。このエラーにより、ユーザーは証明書の失敗を受け入れないと目的の Web サイトにアクセスできない、またはサイトにアクセスできなくなりました。

エラーには一貫性がなく、ユーザーのサブセットに限定されていたのは、すべてのブラウザが Web サイトへのアクセスを許可する前に OCSP の検証を行うわけではなく、また証明書失効リスト (CRL) など、有効性を知らせる他のメカニズムに影響しなかったためと考えられます。

Fastly の対策とレスポンス

Fastly は問題について報告を受けた後、GlobalSign に連絡しました。GlobalSign は調査を行い、根本原因を特定し、誤った OCSP レスポンスを削除することで問題に対処しました。

しかし、それまでに誤ったレスポンスが、オペレーティングシステムの一部でのローカルキャッシュを含む、複数のレベルでキャッシュされていました。レスポンスは通常、その OCSP レスポンスの最終有効日まで格納されます。GlobalSign が発行する OCSP レスポンスは4日間有効であるため、受信したクライアントはそれが4日間有効であると判断します。

GlobalSign の OCSP レスポンダーは、Fastly 以外の CDN を使用し、それがレスポンスをキャッシュした場合に、根本原因への対応が行われた後もレスポンダーがエラーを返していた可能性があります。さらに、クライアントのオペレーティングシステムのキャッシュ動作により、失敗した OCSP レスポンスを使用していた Web サイトにアクセスした一部のクライアントマシンが、そのレスポンスをキャッシュし続けました。その結果、GlobalSign が問題に対処した後もこれらのマシン上のクライアントは影響を受けた Web サイトにアクセスできませんでした。

ユーザーは使用しているマシン上で OCSP キャッシュを手動でフラッシュすることができ、GlobalSign はその方法に関するガイダンスを提供しました。ただし、これはほとんどのエンドユーザーにとって技術的に難しいものでした。さらに、GlobalSign によって提供された回避策はすべての状況で有効であるとは限りませんでした。

Fastly はこれを Fastly のお客様のエンドユーザーに提供するのに適した十分な対策であるとは判断しませんでした。慎重な調査の後、Fastly は問題への対応策としてもう1つのオプションをお客様に提案しました。

• 専用のマップを使用するお客様の証明書は、その問題による影響を受けていない GlobalSign の中間証明機関によって発行された新しい証明書に置き換えられることができます。キャッシュされたエントリーは古い証明書にのみ適用されるため、これらのお客様の問題に完全に対処できます。


• 共有証明書を使用しているお客様は、新しく発行された同様の証明書を持つ追加の共有エンドポイントに移動することができます。Fastly に問題を報告したお客様には、新しいマッピングへの移動を提案しました。

Fastly は、一部のお客様がクライアントアプリケーションで証明書のピン留め (以下の「詳細情報」を参照) を使用していることを認識していたため、お客様から独立して根本原因に対処することができませんでした。そのため、お客様の承認なしに既存のお客様の証明書を新しい中間証明書に即座に置き換えることができませんでした。

解決方法/回避策

失効エラーは、OCSP レスポンスの有効期限 (元のインシデント発生から4日) が切れると発生しなくなります。Fastly によって提供された更新済みマップに移行したお客様は、移行後すぐにその問題が解消されたことを確認できたと考えられます。

Fastly は、お客様がユーザートラフィックを正常に受信し配信するために、サードパーティの認証局と CDN に依存していることを認識しています。このイベントの結果として、Fastly は以下の修復手順と対策手順に取り組んでいます。

• お客様のサービス停止の潜在的な理由として、TLS 証明書の配信におけるサードパーティに起因するエラーを考慮し、インシデントレスポンスのプランを見直しました。このイベントの結果、Fastly は TLS の階層全体を迅速に移行するのに必要なインフラストラクチャを導入しました。さらに、これらのサードパーティベンダーに関して引き続き追加の緊急対応計画を導入します。


• Fastly のステータスページ (status.fastly.com) では GlobalSign の証明書が使用されていたため、そのインシデント発生中に同様の影響を受けていた可能性があります。Fastly では、ステータスを伝達するメカニズムが、CDN を通じたコンテンツの配信に直接影響を及ぼす可能性がある重要なサービス (このケースでは同じ認証局) に依存しないように、同メカニズムを見直しています。


• GlobalSign のサービスについて評価し、Fastly のお客様が使用する GlobalSign の証明書に対する OCSP レスポンスの信頼性を高めます。

Fastly は、ベンダーである GlobalSign と協力し、証明書の発行と失効に関連するイベントのリスクを軽減する対策の導入に取り組んでいます。

詳細情報

証明書の有効性と失効の確認に関する背景

ブラウザが Web サイトに接続し、X.509証明書を評価する際に、そのブラウザは通常、その証明書がまだ有効であることを確認しようとします。これをサポートするため、認証局は X.509 の有効性を複数の方法で確認できます。特定のクライアントがこのインシデントによる問題の影響を受け、他のクライアントが影響を受けなかった理由をお分かりいただくために、参考となる解説を以下に記します。原則として、ほとんどの問題はインタラクティブな OCSP リクエストを実行するブラウザまたはオペレーティングシステムを使用していたユーザーに見られました。

1. CRL : 認証局は、証明書失効リスト (CRL) を発行します。これは、認証局によって失効された証明書のリストを含むファイルです。ほとんどのブラウザでは、リクエストごとに CRL がインタラクティブにダウンロードされることはありません。CRL は一般的にサイズが大きく、接続ごとにダウンロードして有効性を確認した場合、パフォーマンスに大きな影響を及ぼす可能性があるためです。


2. CRLSets : Google Chrome では、証明書を迅速にブロックするメカニズムとして、CRLSets が使用されています。通常、Chrome では OCSP と CRL のインタラクティブなチェックは実行されません。ただし、特定のオペレーティングシステムのライブラリでは、Web ページにアクセスするために、Chrome を使用してシステム上でこれらのチェックが実行される可能性があります。Google は、認証局によって発行された CRL リストをクロールして価値のあるものを抽出し、Chrome ブラウザから自動的にダウンロードできるようにします。


3. OCSP : 認証局は、Online Certificate Status Protocol (OCSP) レスポンダーも有効にします。ブラウザは、このレスポンダーにインタラクティブに照会することで、証明書がまだ有効かどうかを確認できます。多くのブラウザは、TLS 証明書の有効性を確認する際に OCSP チェックをインタラクティブに実行します。正常な OCSP レスポンスが受信されると、結果が正 (有効) または負 (無効) のいずれの場合も、オペレーティングシステムのローカルの OCSP キャッシュに一時保存されます。通常、レスポンスは OCSP レスポンスの最終有効日まで格納されます。GlobalSign の場合、これは4日間でした。


4. OCSP ステープリング : OCSP レスポンスは、OCSP ステープリング (ホチキス留め) と呼ばれるメカニズムを介して Web サーバーによって配信されることもあります。この場合、認証局によって署名された有効性の確認が Web サーバーによって取得され、TLS ハンドシェイク中に「ステープリング」されます。OCSP ステープリングでは、認証局の OCSP レスポンダーへの個別の接続が不要になるため、パフォーマンスとセキュリティの両方においてメリットがあります。ステープリングは、証明書失効のベストプラクティスであり、Fastly フリート全体にデプロイされています。

ブラウザは、有効性のチェックに加え、Public Key Pinning (公開鍵のピン留め) を通じて特定のサイトに対する証明書の有効性をチェックすることがあります。このメカニズムでは、アプリまたはブラウザを問わず、クライアントアプリケーションが、サービスのルート証明書、中間証明書、エンドエンティティ証明書の有効性を検証します。ピンはクライアントにハードコードされるか、Public Key Pinning Extension for HTTP (HPKP) を通じて配布されます。ピン留めは、重要かつ一般的に使用されているセキュリティ機能で、認証局が有効でない証明書をサービスに発行する場合のリスクを軽減します。ただし、ピン留めにより、別の証明書階層に迅速に移動するのに必要な Web サイトの柔軟性が損なわれるおそれもあります。このインシデントでは、Fastly のお客様によるピン留めの使用により、Fastly がすべてのお客様を自動的かつ透過的に別の階層に移行する能力が制限された可能性がありました。

Globalsign のインシデントレポート

GlobalSign は、自社のインシデントレスポンスに関する情報が記載されたインシデントレポートを https://www.globalsign.com/en/customer-revocation-error/ に公開しています。このドキュメントには、この種のインシデントの再発を防止するために GlobalSign が実施した手順に関する詳細情報が含まれています。