Googleのセキュリティチームは3月23日の投稿で、Googleが承認していないGoogleドメインのデジタル証明書をユーザーに配布している人物を発見したと説明しました。迅速な調査の結果、中国の認証局（CA）であるCNNICが、世界中のあらゆるドメインに対して検証可能な証明書を作成できる権限を再販業者に不当に付与していたことが判明しました。
検証可能な証明書があれば、一見安全に見えるWeb接続でも、ブラウザとサーバー間のネットワークポイントに盗聴器を仕掛けられる第三者によって傍受される可能性があります。これは非常に危険な行為です。
詳細はこの記事の後半で説明しますが、重要なのは、この脆弱性が明らかに迅速に発見され、封じ込められたということです。セキュアなWebセッション（そしてセキュアなメールやその他のサービス）の整合性を確保するために徐々に導入されてきた新しいメカニズムは、まさに機能しているのです！
MacとiOSユーザーはSafariではまだこれらの機能を利用できませんが、近々対応予定です。運が良ければ、セキュリティ接続がリダイレクトされ乗っ取られたことを示すエラーが表示されることはまずないでしょう。しかし、もし表示された場合は、この記事が役に立ちます。
ここの責任者は誰ですか?
CAシステムとデジタル証明書の仕組みについて詳しく知りたい方は、2011年のMacworldの記事「MacをWebセキュリティの欠陥から守る」をご覧ください。約4年が経過しましたが、基本的なインフラは変わっていませんが、アドバイスはすべて変化しています。将来的な改善案の中には、消えたり、頓挫したりしたものもありましたが、急速に導入が進んだものもありました。
簡単にまとめると、すべての安全なウェブ接続は、ブラウザとサーバー間のハンドシェイクに依存しています。ブラウザはサーバーからデジタル証明書を受け取ります。この証明書には、公開暗号鍵、ドメイン名を含む証明書の発行元の詳細、そして証明書の情報が改ざんされていないことを検証するために使用される暗号署名が含まれています。公開鍵は、ブラウザとサーバー間のその他の調整を必要とせずに、現在の接続（「セッション」）で使用される暗号鍵を保護するために使用されます。
世界中で数百の組織（企業、非営利団体、一部の政府機関、あるいは政府と密接な関係にある企業など）が証明機関として機能しており、これらの組織はいずれもリクエストに応じてウェブサーバーの証明書に署名できます（ほとんどの場合、有料です）。CAは、証明書に対応するドメイン名を管理する当事者によってセキュリティ文書が提供されたことを証明する、もう一つの信頼レイヤーを提供します。
CAは検証が必要であり、そのためにはOS X、Android、Windowsなどのオペレーティングシステムに暗号データの一部を埋め込む必要があります。多くのブラウザはOSのCAリストを参照しますが、一部のブラウザはOSのCAリストを参照せず、独自のCAリストを保持しています。OS XにAppleが組み込んでいるCAリストを確認するには、キーチェーンアクセス（「アプリケーション」＞「ユーティリティ」）を起動し、左側のキーチェーンリストで「システムルート」をクリックします。
ブラウザが検証できない証明書を受信すると、接続が失敗し、ユーザーに警告が表示されます。これは、おそらく皆さんも目にしたことがあるであろう問題の1つです。これは通常、サーバーの設定ミスや、特定のサーバーで処理されるすべてのドメイン名を含む証明書が作成されていない場合に、偶発的に発生します。
しかし、2011年にお話ししたもう一つのシナリオは、正当で検証可能な証明書がCAまたはその関連機関によって不適切に発行された場合に発生します（ほとんどのCAは再販プログラムを備えており、第三者がCAのバックエンドシステムに接続して処理された証明書を販売することを許可しています）。これは、誤りである場合もあれば、誤った判断である場合もあり、またCAまたはその関連機関への攻撃が原因となる場合もあります。
Google Securityが指摘した事例では、ルートCAが自社の王国への鍵、つまりあらゆるドメインで使用できる証明書の作成を可能にする秘密鍵をリセラーに渡していました。このリセラーは、この秘密鍵をデータ検査装置にインストールしていました。データ検査装置は、企業や政府機関がネットワーク間を流れる機密データを傍受するためによく使用されるものです。
このセキュリティ対策の正当な利用法は、情報の不正使用やセキュリティ漏洩をスキャンする必要があるため、従業員にこの動作を公開する企業や機関です。適切な設定を行うには、ネットワークを使用する前に、個々のマシンにこの検査を可能にするローカル証明書またはプロキシ設定を適用する必要があります。
CA の再販業者が行った行為は、数年前からすべての OS およびブラウザー メーカーによって禁止されています。つまり、すべてのデータを傍受できる汎用のすべてに一致する証明書をインストールする行為です。なぜなら、その証明書は世界中のどこでも使用できるからです。
Googleの警告の正確な原因は不明であり、詳細を尋ねる問い合わせに対して、本コラム執筆時点では回答がありませんでした。しかし、報告内容から判断すると、影響を受けた企業または地域でChromeを使用していたユーザーがエラーを受信し、Googleに報告した可能性が高いと考えられます。この対策はまもなく、より多くのドメインでより広範囲に実施される予定で、警告はほぼすべての最新ブラウザで表示されるようになりました。
証明書の尾をピンで留める
何らかの方法で不正な証明書が発行された場合、CA は失効を発行できる必要があります。失効とは、サーバーからの証明書を受け入れる前に、ブラウザーやその他のソフトウェアによって送信され参照される、不正の自動「ステートメント」です。
キーチェーンアクセスの「環境設定」の「証明書」タブで、失効処理の方法を確認（および設定）できます。細かい点には触れませんが、この処理は信頼できるとは言えません。失効サーバーは常に利用できるとは限らず、利用できない場合は、検索によってブラウザがロックされたり、タイムアウトになったりして、証明書が失効しているかどうかに関係なくそのまま受け入れてしまうことがあります。（失効を管理する新しい方法が普及しつつありますが、まだ十分に普及していないため、信頼できるほどではありません。）
代わりに、OS およびブラウザのメーカーは、特定の証明書または証明書セットを無効にするか、CA から再販業者などの別の当事者に割り当てられた「中間」ルート証明書をブロックするために、警告を発し、多くの場合は自動修正としてマイクロアップデートをプッシュします。
ただし、サイトとユーザーに通知を提供する方法として 2 つのアプローチが注目されており、そのうちの 1 つについては 2011 年に少し触れました。
クライアント側では、「ピンニング」は不正な証明書に対する部分的な万能薬です。ピンニングが導入される前は、世界中のどのCAとその認証局が認可した組織でも、世界中のどのドメインでも有効な証明書を発行できました。恐ろしい状況です。まるでブラジル（あるいはケニア、ウクライナ、ユタ）のオフィスにいる人に、バルセロナのアパートの鍵を作って売らせるようなものです。
ピンニングは、数百ある認証局（CA）の中から、ドメインの証明書を発行する権限を持つ認証局（CA）を明示的にリスト化します。他の認証局（CA）によって署名された証明書が見つかった場合、警告が鳴ります。Googleはこれを先駆的に導入し、現在ではその範囲を拡大しています。Googleは2011年からChromeブラウザ内でドメインをピンニングしており、Chromeユーザーがローカルピンも入力できるようにしています。これは、Chromeを大量に導入している企業にとって便利です。
Mozilla（Firefoxの開発元）は2014年のバージョン32で、自社ドメインとTwitterドメインを含む複数のドメインにピン留め機能を追加しました。その後のリリースでこの機能を拡張し、Googleなどのドメインも追加しました。
こうした特殊なケースではそれで十分ですが、このツールはすべてのセキュアなサイトで利用できるべきではないでしょうか。私はここ数年、Web証明書の認証局（再販業者ではありますが）を数社しか利用していません。私のサイトに接続したと勘違いしたユーザーに対する理論的な攻撃をブロックできれば素晴らしいのですが、ましてや小規模な信用組合の銀行サイトや大手小売店のサイトなどではなおさらです。
あらゆるサイトがWebサーバー経由で有効な認証局を公開できる汎用的な方法が数年前から開発されており、導入が始まっています。HTTP Public-Key-Pinning（HPKP）の略称で呼ばれています。現在FirefoxとChromeがサポートしており、将来的には主要ブラウザすべてに必須の要素となると思われますが、期限や発表はまだありません。
この悪用は見抜ける
2つ目の助けとなるのは、Googleが推進し、現在も展開を進めている証明書の透明性（CT）です。CTが導入されると、すべての認証局（CA）は、新しい証明書が発行されるたびに（あるいは数時間前に）、中央のログに情報を公開することが義務付けられます。これにより、Googleをはじめとする世界中の組織は、すべての正当な証明書を追跡できるだけでなく、ピンニングに基づいて、権限のない認証局によって発行された証明書も把握できるようになります。
CTがブラウザとオペレーティングシステムにピンニングと併せて完全に実装されると、対応するCAの証明書発行リストに載っていない証明書やピンニングテストに失敗した証明書に対して、ユーザーは対応策を講じる機会を得られます。CTは、Googleなどの企業や独立したセキュリティ組織でも、問題のあるセキュリティ文書を積極的に監視するために利用されるでしょう。
ピンニング、そして近い将来導入される証明書の透明性は、証明書の不正使用に関連するすべての問題を解決するわけではありません。しかし、これらを単独で、あるいは組み合わせることで、スニファーが証明書を入手して安全な接続に侵入し、即座に発見されることをはるかに困難にし、潜在的な危害の範囲を縮小します。
ブラウザが提供するアラートにより、ユーザーは、インターネットの配管に整合性をもたらす取り組みに参加しているという実感を正当に得ることができます。
訂正：本記者は当初、HPKPではなく別のセキュアウェブ標準であるHSTSを参照していたため、ブラウザのサポート状況を誇張していました。記事を更新し、訂正しました。
