セキュリティ専門家は、トラストストアの変更が適用される中、ブラウザ以外も含めて証明書への依存関係を見直すよう組織に促しています。
インドのデジタルトラスト企業eMudhraは、8つの中間認証局(CA)の秘密鍵が侵害されたことを受け、グローバルなSSL/TLS証明書事業から撤退すると発表しました。代替として、Sectigoが発行する証明書を顧客に提供します。
eMudhraはプレスリリースで、取締役会が「グローバルなSSL/TLS証明書事業から自主的に撤退する」ことを決定したと述べています。データ主権やコンプライアンスの要件により、事業の複雑さとコストが増していたとも説明しています。
eMudhraのV Srinivasan会長は発表の中で、「今回のインシデントを巡るソーシャルメディアでの拡散により、当社事業におけるSSL/TLSの位置づけに不釣り合いなほどの注目が集まった」とコメントしています。
同社は、影響を受ける顧客に連絡し、証明書を無償で交換するとしています。また、発行済みのすべての証明書が失効または交換されるまで、失効情報や証明書ステータスのサービスを継続するとしています。
代替としてSectigoを提案
eMudhraは顧客向けの更新情報で、Sectigoが発行する証明書をすべての顧客に提供すると明らかにしました。
同社は更新情報で「当社のG1ルート証明書は引き続き有効であり、全面的にサポートされます」と説明しています。10月22日付のリリースでは、G1 RSAルートは「この移行が完了するまで顧客へのサービスを継続する」としています。
eMudhraによると、パートナー経由で代替証明書を無償で提供し、同社が発行したすべての証明書が失効または交換されるまで、失効情報と証明書ステータスのサービスを運用し続けます。声明によれば、CertiNextのユーザーはアカウントからSectigo証明書を申請できます。それ以外の顧客はeMudhraのサポートに問い合わせてください。
Gartnerのプリンシパルアナリスト、Niyati Daftary氏は、組織はG1ルートを「最終的な移行先ではなく、あくまで橋渡しになり得るもの」と捉えるべきだと指摘します。
Daftary氏は「同社はグローバルなSSL/TLS事業から撤退し、残るルートもブラウザの厳しい監視下にあります。期限が許す限り、重要なサービスは独立した完全に信頼できるCAへ移すのが賢明です」と述べています。
即時の障害を避けるためにG1を使う場合は、明確な期限を設定し、その後の移行計画を文書化するよう勧めています。
さらに、サードパーティリスク評価には、発行機関、中間証明書とルート証明書、クロス署名の取り決め、失効インフラ、ブラウザにおける信頼状況を含めるよう助言しています。
Security Brigadeの共同創業者兼CTO、Yash Kadakia氏は、同じ企業が運営する別のルートに移行しても、信頼性やガバナンスへの懸念が解消されるとは限らないと話します。
Kadakia氏は「組織にとって最悪なのは、2度移行する事態です」と述べています。
Sectigoは、コメントの求めにすぐには応じませんでした。
Javaなどのシステムでは個別の対応が必要な可能性
IDCのリサーチディレクター、Sakshi Grover氏によると、Webサイトの証明書を交換するだけでは、企業環境のあらゆる依存関係には対処できない可能性があります。残存するリスクは、独自のトラストストアを持ち、ブラウザと同じスケジュールで更新されないシステムにあるといいます。具体的には、Javaキーストア、言語ランタイム、コンテナイメージ、相互TLS(mTLS)の構成、プロキシ、ロードバランサー、VPNやセキュリティアプライアンス、組み込み機器などです。
Grover氏は、ブラウザやOSの外で証明書の信頼判断がどこで行われているかに触れ、「多くの組織にとってより厄介なのは、こうした問いにそもそも答えられないと判明することでしょう」と述べています。
Grover氏によれば、Googleは、影響を受けた中間証明書がブロックされる前に、それらにチェーンする証明書をCertificate Transparencyログ内で確認していません。Certificate Transparencyを強制するクライアントにとっては安心材料ですが、一部のブラウザ以外のアプリケーションや機器は強制していません。また、悪用には通信を傍受できる位置に攻撃者がいる必要があるため、残るリスクは広範ではなく、限定的で標的型のものだと説明しています。
JavaベンダーのAzulは声明で、Javaは既定では証明書の失効を確認しないと説明しています。そのため、パッチを適用していないJava Development Kit(JDK)は、該当するチェーンが信頼されたままであれば、侵害された中間鍵で署名された偽造証明書を受け入れ続ける可能性があります。
Azulは、Azul Zulu Builds of OpenJDKとAzul Primeの更新版をリリースしたとしています。この更新で、影響を受けた8つの証明書がJDKのブロック対象証明書リストに追加されたといいます。
Grover氏は、セキュリティチームはまず、ブラウザやOSの外で信頼判断が行われている箇所を特定するよう推奨しています。その際は、外部からの接続を受け付けるシステムや、相互TLSのエンドポイントを優先します。次に、特定の中間証明書や公開鍵を信頼しないよう更新できるシステムを見極めるべきだと述べています。
証明書保有者に向けたChromeの期限
Mozillaは、侵害された8つの中間証明書に署名したルート「emSign ECC Root CA – G3」を、トラストストアから削除しました。Googleはブログ記事で、このルートのChrome Root Storeからの削除が、太平洋時間10月27日午前中にすべてのデバイスに行き渡る見込みだと説明しています。
Googleは記事の中で「障害を避けるため、emSign ECC Root CA – G3にチェーンする証明書を使うWebサイトの運営者は、直ちに新しいTLS証明書を取得して導入する必要があります」と呼びかけています。
Daftary氏は、企業は証明書の再販業者は把握していても、自社の信頼を支えるCAの階層構造までは把握していないことが多いと指摘します。
Daftary氏は「その結果、何千ものサービスに一度に影響しかねない、認識されていない第4者リスクが生まれます」と述べています。さらに、CISOはサードパーティのサイバーリスク評価に、発行CA、ルート、クロス署名の取り決め、失効インフラを含めるべきだと付け加えました。Kadakia氏は「サービスを外部に委託することはできても、説明責任まで委託することはできません」と話しています。
