Symantec発行証明書問題を考える

ニュースソース:Venafi Blog

以下は 2017年4月20日に公開された Symantec: What Should We Do as an Industry?を要約したものです。


2017年3月24日、Googleチームがシマンテックに対し、シマンテックの証明書には誤発行が多く信頼するには十分ではないため、証明書発行プロセスの是正を求めました。
この件は決着がついておらず、シマンテックとブラウザベンダー(Chrome、Firefox)間の議論が多くの注目を集める中、Googleによって「シマンテックにはいくつもの監査されていない下位認証局が繋がっている」等の新しい情報も明るみに出ています。
また追加の情報がシマンテックから報告される可能性もあります(Mozillaがシマンテックに4月20日までに情報開示するように要求)。
結果として、Googleは当初発表していたシマンテックへの対処(証明書有効期限の短縮)をさらに変更することが予想されます。

こういった証明書発行の問題に対し、ブラウザベンダーに対応を任せるだけでなく、業界全体がとれる以下3タイプの行動オプションをメリット・デメリットも併せていくつか提示したいと思います。

  1. 問題の指摘されたタイプの証明書をそのままにする

    現状のシマンテック証明書を信頼できるものとして同意し、今後シマンテックがポリシーを強化、改善していくことを信じる(現にシマンテックは外部登録局(RA)の除外等いくつかの変更を加えています)。

    • メリット
      証明書が発行時に約束された期限まで有効なため、サイト管理者やユーザーの混乱を最小限に抑える事ができます。
    • デメリット
      Baseline Requirementsが意味をなさなくなります。
      業界がこのオプションを選ぶことにより、認証局(CA)はCA/ブラウザフォーラムが定めた基準Baseline Requirementsを無視しても良いという判断に至ってしまう可能性があります。
      基準を無視した認証局(CA)は大きな問題を起こした際に評判が落ち、ビジネスに大きな損害が出ます。しかし逆に言うと、適正基準を守るように強制して未然に問題を防ぐことをしないため、大きな問題が起こるまで待つことになります。
      また、Baseline Requirementsを守るために活動していた認証局(CA)も守るための動機がなくなり、活動を縮小する可能性があります。
  2. シマンテックが自ら修正する

    シマンテックから現存の全顧客にコンタクトして全ての証明書を置き換えてもらいます。またGoogleのように、現存の証明書をスケジュール立てして廃止し、置き換えていくという手段もあります。
    シマンテックはすでに、もしGoogleがスケジュールを進めていくのであれば証明書を無償で交換することも示唆していますが、このオプションにおいてはサイト管理者に積極的に行動してもらう前提となります。

    • メリット
      シマンテックが現状の問題をインターネットセキュリティの完全性を守るために修正するべきだと捉え、行動している姿勢を示すことができます。
      責任を果たすために問題点に積極的に対応することで、結果的にシマンテックは評判が下がるのを避けることができます。
    • デメリット
      証明書の置き換えにはサイト管理者による作業が必須ですが、全てのサイト管理者の最新連絡先の入手が困難だったり、サイト管理者がタイムリーに対応してくれるとも限らないという問題があります。
      証明書を廃止して置き換える案に関しては、証明書廃止のチェックはアプリケーションやシステム側では強制されないため、信頼性のある変更方法とは言えません。
      また、すでにシマンテックから悪用可能な証明書を手に入れた攻撃者は最大限長く保持しようとすることでしょう。
  3. Googleが提案した変更を実施してもらう

    Googleはシマンテックとの協議を終えて、内部での許可が下りたら計画通りにシマンテック証明書の期限切れを進めていくでしょう。他のブラウザも続くかもしれません。

    • メリット
      現存の疑わしいシマンテック証明書は可能な限り迅速に置き換えられていきます。
      この変更により、証明書のセキュリティの重要性とPKI構成要素の必要性の認識が認証局(CA)だけでなく利用者にも強まります。
      さらに、大規模なCAインシデントや他のPKIインシデントに対応する必要性を認識することができます。
    • デメリット
      多くのサイトが当初の有効期限より前に信頼されなくなるため、サイト管理者とユーザーの双方に混乱が及びます。

オプション2と3は協力して潜在的混乱を減少させることができ、状況に合った対応だと考えられます。