GlobalSign は、世界のルート証明機関の 1 つとして、どのようにして Web の一部を破ることができたのか、事後調査を実施した。
米国ニューハンプシャー州に拠点を置くこの企業は、これまでに世界中のウェブサイトに250万件のSSL/TLS証明書を販売してきました。今週、同社は意図せずして自社の信頼チェーンを破壊してしまいました。つまり、世界中のウェブブラウザやアプリにとって、顧客の証明書が信頼できないものに見えるようになってしまったのです。
これにより、Wikipedia やFinancial TimesからGlobalSign 独自のサーバーに至るまで、大小さまざまな安全な Web サイトやオンライン サービスに多くの人がアクセスできなくなりました。
この偶発的なミスは、すべての人に影響を与えているわけではありません。もしあなたのパソコン、スマートフォン、その他のガジェットが、10月13日木曜日にGlobalSignのネットワークから不正な失効リストを取得してしまった場合、ブラウザは正規のHTTPSウェブサイトへのアクセスをブロックします。これは、GlobalSign発行の暗号化証明書が無効になったとブラウザに通知されたためです。
この失態に見舞われた技術に詳しいネットユーザーは、失効リストのキャッシュをクリアし、GlobalSignから修正情報を取得することで問題を解決できます。一方、技術に詳しくないユーザーは、不可解なブラウザエラーメッセージが表示されるだけです。ウェブ閲覧中に画面にエラーメッセージが表示されない場合は、お使いのパソコンやスマートフォンが既に修正を検知しているか、GlobalSign証明書を使用していないウェブサイトにアクセスしているか、あるいはブラウザが今回の小さな危機を完全に回避している可能性があります。
技術詳細
当初、GlobalSign 社は、この失敗の原因を Web ブラウザのプログラミング上の欠陥だとしたが、その後、問題は自社のシステムにあることに気付いた。
すべては、GlobalSign が、組織のルート CA R2 証明書によって署名された証明書失効リストを公開したことから始まったと言われています。このリストでは、相互証明書と、廃止される予定だった古い従属 CA が失効されていました。この従属 CA は、古い SHA1 拡張検証 SSL 証明書を発行するために使用されていました。
一般的に、相互証明書は信頼性と信頼性を向上させるために使用できます。GlobalSign の場合、相互証明書により、ブラウザとアプリは GlobalSign が発行した HTTPS 証明書の整合性を GlobalSign のルート CA R1 またはルート CA R2 証明書で検証できます。
したがって、クロス証明書は、ウェブサイトのHTTPS証明書の有効性を確認する際にソフトウェアが辿る2つの信頼パスを作成します。ブラウザがGlobalSignのルートCA R1またはR2のいずれかを信頼している限り、チェーンの最後でサイトのHTTPS証明書を信頼します。
GlobalSign が失効させようとしていたのは、相互証明書と古い従属 CA だけです。
相互証明書は、GlobalSignのルートCA R2によって、ルートCA R1をサブジェクトとして発行されました。失効リストが公開されてから6日後の10月13日、GlobalSignは委任されたオンライン証明書ステータスプロトコル（OCSP）レスポンダデータベースと呼ばれるデータベースを更新しました。このデータベースは、委任された失効レスポンダと呼ばれる一連のシステムに情報を提供します。
予想外にも、これらの回答者は相互証明書の失効に混乱し、GlobalSignがルートCA R1証明書にリンクされた中間証明書を失効させようとしていると考えました。これらの中間証明書は、ウェブサイトや企業に販売されるSSL/TLS証明書の発行に使用されます。中間証明書を失効させると、すべての顧客証明書が信頼できなくなり、事実上無効になります。信頼チェーンが破壊されたため、ブラウザはGlobalSign証明書を使用している安全なサイトのIDを検証できなくなり、ウェブサイトへのアクセスを拒否します。
「委任失効対応者は、相互証明書がより新しい日付で同じ公開鍵とサブジェクト名の詳細を持っていたため、相互証明書がルート CA R2 によって失効されたため、すべてのルート CA R1 中間証明書が『不良』であると誤って判定しました」と GlobalSign は事後に作成されたインシデント報告書で説明しています。
同社は最終的に失効リストの変更をロールバックしましたが、既に手遅れでした。変更はコンテンツ配信ネットワーク（CDN）を通じて、最新の失効リストを取得するためにGlobalSignに問い合わせていたアプリケーションにまで波及していたのです。一部のブラウザやプログラムは正しいデータを受信しましたが、不運なアプリは不正なリストを受け取り、GlobalSignの仲介業者を当然のように排除しました。
「この状況はロールバックされ、ロードバランサーとCDNは削除されましたが、一部のユーザーは『悪い』応答を維持していました。一方、多くのユーザーは、GMOグローバルサインのSSL対応ウェブサイトとの以前のやり取りから以前の『良い』応答を維持していました」と同社は説明した。
つまり、失効応答側で実行されているソフトウェアは、クロス証明書の公開鍵とサブジェクト名がルート CA R1 証明書のものと一致し、クロス証明書の有効開始日がより新しいことを確認し、クロス証明書が削除されるので、R1 の従属証明書もすべて削除する必要があると判断したことになります。
GMO GlobalSignは、製品ラインナップ全体、そしてお客様とその証明書利用者コミュニティ全体への委任レスポンスの提供にあたり、サードパーティのセキュリティ認定を受けた負荷分散型OCSPレスポンダシステムを使用しています。しかしながら、当社のエコシステム、ステークホルダー、そしてそのお客様にとって残念なことに、レスポンダのコードベース内のロジックにより、ルックアップテーブル内の公開鍵とサブジェクト名で識別された相互証明書の失効が、DomainSSLやAlphaSSLを含む他のすべての従属証明機関も「不正」と判断する指示と解釈されてしまいました。
ロジックは、クロス証明書のより新しい Not-Before Date (Valid From) を元のルート CA R1 よりも後のアサーションと見なし、したがってこれをルート CA R1 が発行したすべての従属証明書を「不良」としてマークするための正式な指示であると判定しました。
問題のあるコードのベンダー名は明らかにされていません。もしご存知の方がいらっしゃいましたら、ぜひお知らせください。以下は、ブラウザやその他のクライアント側ソフトウェアが接続するロードバランサーや配信システムのレイヤーを、この誤った決定がどのように通過したかを示しています。変更は統一された方法で送信されなかったため、一部のデバイスやコンピューターが誤った失効リストを取得することを免れました。ブラウザやその他のアプリケーションは数日ごとに失効を確認する傾向があるため、アップデートのために電話で連絡するタイミングがなかったとしたら、今週のドラマを見逃していたことでしょう。
GlobalSign のチームによって、完全な技術的詳細がここで説明されており、問題でまだ困っている人のために追加のサポート情報と FAQ も記載されています。
業界関係者は、キャッシュ処理の多さと、アプリケーションが失効リストの更新を4日に1回チェックする傾向があることから、この問題が完全に解消されるまでには来週初めまでかかる可能性があると警告しています。木曜日にソフトウェアが攻撃を受けた場合、月曜日まで対策が講じられない可能性があります。®
PS: HTTPS 証明書には GlobalSign の代替手段があります。たとえば、無料で証明書を配布する Let's Encrypt などです。
