WH

ITE PA

PER

:

powered by Symantec

White Paper

SSL ハンドシェイクの裏側証明書失効確認メカニズムSSL サーバ証明書が情報漏えいに強い理由

White Paper : SSL ハンドシェイクの裏側

2

Copyright ©2014 Symantec Corporation. All rights reserved.　Symantec と Symantec ロゴは、Symantec Corporation または関連会社の米国およびその他の国における登録商標です。その他の会社名、製品名は各社の登録商標または商標です。

合同会社シマンテック・ウェブサイトセキュリティは、本書の情報の正確さと完全性を保つべく努力を行っています。ただし、合同会社シマンテック・ウェブサイトセキュリティは本書に含まれる情報に関して、（明示、黙示、または法律によるものを問わず）いかなる種類の保証も行いません。合同会社シマンテック・ウェブサイトセキュリティは、本書に含まれる誤り、省略、または記述によって引き起こされたいかなる（直接または間接の）損失または損害についても責任を負わないものとします。さらに、合同会社シマンテック・ウェブサイトセキュリティは、本書に記述されている製品またはサービスの適用または使用から生じたいかなる責任も負わず、特に本書に記述されている製品またはサービスが既存または将来の知的所有権を侵害しないという保証を否認します。本書は、本書の読者に対し、本書の内容に従って作成された機器または製品の作成、使用、または販売を行うライセンスを与えるものではありません。最後に、本書に記述されているすべての知的所有権に関連するすべての権利と特権は、特許、商標、またはサービス ･ マークの所有者に属するものであり、それ以外の者は、特許、商標、またはサービス ･ マークの所有者による明示的な許可、承認、またはライセンスなしにはそのような権利を行使することができません。

合同会社シマンテック・ウェブサイトセキュリティは、本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます。

White Paper : SSL ハンドシェイクの裏側

3

CONTENTS

1．はじめに 4

2．証明書失効情報確認のメカニズム 4CRL（CERTIFICATEREVOCATIONLIST：証明書失効リスト）とは？ 4

OCSP（ONLINECERTIFICATESTATUSPROTOCOL：オンライン証明書ステータス確認プロトコル）とは？ 6

3．ユーザビリティとセキュアな通信　　～証明書失効情報確認における課題～ 73-1認証局の取り組み 7

3-2ウェブブラウザの対応状況 7

3-3.新たなメカニズム採用への取り組み 8

OCSPステープリング 8

短期証明書（SHORT-LIVEDCERTS） 9

4．おわりに 10

White Paper : SSL ハンドシェイクの裏側

4

1．はじめに

認証局には SSL サーバ証明書を「発行する」という役割に加えて、証明書を「失効する」という大切な役割があることをご存じですか？パスポートや運転免許証等本人を特定できる身分証明書、もしくはクレジットカードを紛失してしまった時、他人に悪用されてしまうのではないかと不安になります。SSL サーバ証明書の所有者が秘密鍵を紛失するということは、身分証明書を紛失すると同じこと。所有者の依頼、もしくは認証局 (CA) が危殆化していると判断した場合、認証局はその証明書を利用できないように「失効」させることがあります。失効された SSL サーバ証明書の情報はインターネット上で公開されており、皆さんが証明書を利用して SSL 通信を行う際に、このリストを自動的に参照するメカニズムが働き、アクセスするウェブサイトの証明書は失効されておらず有効である、つまり信頼できるかどうかを確認しているのです。

失効を確認するメカニズムが正しく働かないと、例えば、秘密鍵が他人に盗まれたウェブサイトでは悪意のある第三者が運営者になりすまし、いわゆる中間者攻撃（MITM：Man-in-the-Middle）を容易に仕掛けることができ、インターネットの安全が大きく脅かされる事態につながります。

このメカニズムにおいて、認証局は SSL サーバ証明書の失効情報を閲覧可能な状態にしておかなければならないという重要な役割を担っています。認証局の失効情報公開インフラのパフォーマンスは、SSL ハンドシェイクの通信速度の遅延、しいては SSL通信の成功・失敗に影響を与える可能性さえあります。

このホワイトペーパーでは SSL サーバ証明書の失効情報を管理する失効リストや確認プロトコルの仕組みと、パフォーマンスなどに与える影響、その影響を克服するための取り組みに関して説明します。

2．証明書失効情報確認のメカニズム

SSL サーバ証明書のステータス情報確認を行うための方法として一般的には、CRL（証明書失効リスト）と OCSP（オンライン証明書ステータスプロトコル）が利用されています。どのようにして証明書のステータス情報確認を行っているかは、利用するブラウザによって異なります。

CRL

（Certificate Revocation List：証明書失効リスト）とは？

認証局（CA）

ウェブサーバ

ウェブサイト利用者

1. SSL ハンドシェイク

2. CRL（ダウンロード済み）と照合

3. SSL 通信開始

SSLサーバ証明書

CRL

0. CRL をダウンロード

図 . CRL

White Paper : SSL ハンドシェイクの裏側

5

CRL は認証局が現在失効している全証明書のリストです。各ウェブブラウザは、証明書の署名検証時に CRL をダウンロードし、該当の証明書が CRL に含まれていないかを照合します。CRL のプロファイルはインターネット技術標準化委員会（以下、IETF） のRFC5280 で定義されています。CRL には CRL 発行人、CRL を発行した日（ThisUpdate）と次回更新予定日（NextUpdate）、CRL 発行人の署名が含まれています。認証局は CRL を定期的に（毎時、毎日、あるいは毎週）発行し、ブラウザは最新の CRLを取得して証明書の有効性を照合します。CA/Browser Forum が定める Baseline Requirements ※ 1 には、認証局は少なくとも 7 日毎に CRL を更新および再発行すべき（SHALL）で、その有効期間は 10 日間を超えてはならない（MUST NOT）と規定しています。

CRL には、完全 CRL とデルタ CRL があり、完全 CRL は認証局が失効した証明書のシリアル番号と失効日すべてを含んでいるのに対し、デルタ CRL は完全 CRL との差分、つまり最終発行日以降に失効した証明書情報のみが含まれています。

図 . CRL サンプル

CRL は、比較的小規模な限られた利用者の中で利用するプライベート PKI における失効情報確認方法に適しているのですが、SSL サーバ証明書のようにインターネットのありとあらゆるところで利用されるパブリック PKI の場合、各認証局が取り扱う証明書数が膨大となるため CRL のファイルサイズが必然的に増大する傾向にあり運用が問題となることがあります。ファイルサイズの増大、CRL ダウンロードリクエスト数の増加は認証局の CRL サーバへの負荷を高め、認証局は CRL の頻繁な配布を制限せざるを得なくなります。また、ウェブサイト利用者（クライアント）側も、ダウンロード時の帯域の消費、メモリの圧迫等負担が増え結果的にページが表示されるまで時間がかかります。より円滑な SSL 通信を実現するため、多くのクライアントは頻繁な CRLダウンロードを避け CRL の有効期間内（nextUpdate：CRL の次回更新予定日まで）はクライアントに CRL をキャッシュしています。

また、差分のみを提供する DeltaCRL は CRL ファイルサイズを抑えるための施策として利用されていますが、結果的には元 CRLと差分照合、クエリ処理がより複雑になりクライアントのシステムの負荷を解消する根本的な解決策ではありません。

※ 1： CA Browser Forum とは、世界の認証局、ブラウザベンダーで構成される非営利の業界団体で、シマンテックもその会員です。2012 年 7 月 1 日には、認 証局の運用、証明書仕様、認証などの最低限のルールを決める Baseline Requirements を発効しています。　http://www.cabforum.org/

White Paper : SSL ハンドシェイクの裏側

6

OCSP （Online Certificate Status Protocol：オンライン証明書ステータス確認プロトコル）とは？

図 . OCSP

認証局（CA）

ウェブサーバ

OCSPレスポンダ

ウェブサイト利用者

SSLサーバ証明書

CRL

データベース

1. SSL ハンドシェイク

3. SSL 通信開始

2. OCSPリクエスト OCSPレスポンス

OCSP は、単一の証明書のステータスについて確認するための http プロトコルです。ウェブブラウザは http のパケットに証明書ステータス確認要求（以下、OCSP リクエスト）を追加して、オンラインで OCSP サーバ（OCSP レスポンダ）に要求します。要求する際には、証明書を識別するために証明書のシリアル番号、証明書発行者の Distinguish Name のハッシュ値、発行者の公開鍵ハッシュ値を指定しなければなりません。この要求に対して、OCSP レスポンダは、証明書のステータスを“good”（失効していない）、“revoked”（失効している）、“unknown”（不明）のいずれかに分類し応答 ( 以下、OCSP レスポンス ) を返します。OCSP レスポンスには信頼できる OCSP レスポンダからの応答であること、また内容が通信途中に改ざんされていないことを証明するためにデジタル署名が付いています。ウェブブラウザは受信する OCSP レスポンスが、要求した内容であること、署名が有効であること、署名者が承認されたレスポンダであること、署名日時が十分に新しいことを確認し応答を受け入れます (accept)。

OCSP は IETF RFC2560 に定義されていますが、あくまでもオンライン証明書ステータスプロトコルについての記述となります。OCSP はリアルタイムに失効情報を回答する仕組みですが、そのレスポンスが常にリアルタイムの証明書ステータス情報であるとは限りません。OCSP レスポンダが参照する失効情報データは、CRL を参照している場合もあれば、認証局のデータベースを直接参照していることもあり認証局によって異なります。CRL を参照している場合、OCSP レスポンスのデータの“鮮度”は CRLと同等となります。Baseline Requirements では、認証局は少なくとも 4 日毎に OCSP 経由で提供される情報を更新するものとする（SHALL）。このサービスからの OCSP レスポンスの有効期間は 10 日以下でなければならない（MUST）、としています。※ 2

OCSP は、CRL と異なり単一の証明書ステータス情報を問い合わせるメカニズムであるため認証局が失効した証明書の総和に関係なく、一回のデータ量が一定です。ただし、https ハンドシェイク時にクライアントが OCSP レスポンダへ照会、レスポンダがレスポンスに署名、そして受信したレスポンスをクライアントが署名検証するという複数のステップをふむため https ハンドシェイクの全体的な処理時間が長くなります。データ通信量や通信速度によってウェブサイト訪問者は http 通信のウェブサイトと比較するとhttps のサイトは表示されるのに時間がかかる、と体感するようになるかもしれません。

※ 2： CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.3, https://www.cabforum.org/Baseline_Requirements_V1_1_3.pdf

White Paper : SSL ハンドシェイクの裏側

7

もうひとつ、SSL ハンドシェイクの処理速度を低下させる要因として、OCSP レスポンダの処理能力が挙げられます。より多くの人が https でウェブサイトへアクセスすると OCSP レスポンダへのオンライン照会が増えシステム負荷が高まります。認証局が常にこれらの要求にこたえられる処理能力、可用性 (Availability) を持たない場合、レスポンスの遅延や通信タイムアウトを招き結果としてハンドシェイクの失敗、https 通信が遮断されてしまいます。特に、ウェブサイトのアドレスバーを緑に表示する EV SSL 証明書を用いたウェブサイトの場合、都度 OCSP でステータス確認を行うことが EV ガイドラインにて定められておりOCSP レスポンダの処理能力はクリティカルな要因となります。

3．ユーザビリティとセキュアな通信 ～証明書失効情報確認における課題～

CRL や OCSP はウェブサイト利用者の安全な通信を確保するためのメカニズムですが、安全性を重視するだけでなくウェブサイト利用者のユーザビリティを下げずに実装されることが重要です。CRL および OCSP を提供する認証局は、クライアントからの要求に対して常に応対する 100％の可用性、そして要求に対して迅速に応答するための高い処理能力が求められます。特に OCSP の場合は、https 通信毎にリクエストされるオンライン照会なので、より厳しく要求されます。

3-1 認証局の取り組みより高速な https 通信を実現するために、認証局はサーバ台数を増やして負荷分散をする、サーバを世界各地に分散させ利用者が地理的に近い OCSP サーバへアクセスさせる、CDN（Contents Delivery Network）を利用してレスポンスタイムの短縮を図る等システムを改善することができます。しかし実態はどうでしょうか。

2012 年 11 月から実際に約 40 の OCSPレスポンダの URL をモニタリングしている Netcraft は、OCSPレスポンダのサービスパフォーマンスと信頼性は、レスポンダ（つまり認証局）によって著しく異なると述べています。※ 3 背景には、システム強化による認証局の運用コスト増加が挙げられるでしょう。サーバ運用コストを下げる策として一部のサービスを第三者機関に委託することもありますが、Netcraft によれば、サービスを第三者に委託した結果、OCSPレスポンスのパフォーマンスは向上したが委託先のサービス品質に影響されて可用性が下がっている認証局もあると指摘しています。このような認証局の対応の違いは、同じ https 通信でもどの認証局から発行された証明書を用いているかによって、ウェブサイト利用者のユーザビリティに影響を及ぼすといえるでしょう。

3-2 ウェブブラウザの対応状況では、ウェブブラウザは SSL サーバ証明書のステータス情報を確認するためどのような対応をとっているのでしょうか？ブラウザベンダはセキュアな環境を提供するとともに、やはりユーザの利便性を落とさないこと、特に通信速度の改善に力を入れている傾向にあります。

CRL OCSP

SSLサーバ証明書 EVSSL証明書 SSLサーバ証明書 EVSSL証明書

Internet Explore ○ ○ ○ ○

Google Chrome △ ○ △ ○

FireFox △ △ ○ ○

Opera ○ ○ ○ ○

Safari △ ○ △ ○

○ = サポートしている、　△ = サポートしている、ただしデフォルト設定は OFF

Firefox では、中間 CA 証明書の OCSP レスポンスをキャッシュすること や、全階層の OCSP 処理順を順次処理するのではなく同時処理する議論がされていますし※ 4 ※ 5、Windows の PKI のコンポーネントである CryptoAPI Version2.0 ではLightweight OCSP を採用していたり、と対応は様々です。Windows の CryptoAPI は、Windows Vista 以降、IE8 以降に搭載されています。※ 6 Lightweight OCSP は、SSL 通信量が増えていく中でスケーラビリィと費用対効果のあるオンライン失効情報問い合せメカニズムで、IEIF RFC5019 に定められています。

※ 3： Netcraft, Certificate revocation and the performance of OCSP, http://news.netcraft.com/archives/2013/04/16/certificate-revocation-and-the-performance-of-ocsp.html

※ 4： Bugzilla, Bug 48597, https://bugzilla.mozilla.org/show_bug.cgi?id=48597※ 5： Bugzilla, Bug 579606, https://bugzilla.mozilla.org/show_bug.cgi?id=579606※ 6： Microsoft, オンライン　レスポンダのインストール、構成およびトラブルシューティング ,

http://technet.microsoft.com/ja-jp/library/cc770413(v=ws.10).aspx

White Paper : SSL ハンドシェイクの裏側

8

Lightweight OCSPの特徴1． あるサーバのSSLサーバ証明書のステータス確認を行う前に、証明書発行元CA証明書が失効されていないかを事前に確

認し、すでに失効されている場合はOCSP要求を行なわない、その時点でエラーとする。2． OCSPの要求/応答メッセージの内容を簡素化し通信時のメッセージサイズを小さくすることで通信帯域の使用量を軽減す

る。3． ネットワークおよびクライアントに一時的にキャッシュさせることで要求・応答の往復処理時間を短縮する。

このような取り組みが行われる一方、Google のセキュリティ技術者である Adam Langlay 氏は 2012 年 2 月に将来的にGoogle Chrome で証明書失効情報の確認手段として、CRL や OCSP を利用することをやめる方針であることを表明し※ 7、議論を巻き起こしました。（EV SSL 証明書は除く）このような方針に至った主な理由としては、1）Captive Portal などの環境や CAシステムがダウンしていると OCSP レスポンダに到達できない、結果として多くのブラウザでは“soft-fail”処理（実質上 OCSPレスポンス結果を無視）しており実際には証明書ステータス確認は機能していない、一方、2）OCSP は通信処理量が増えページのロード遅延を招き、運用コストがかさむだけで利点が得られないとしています。2011 年、Comodo や Diginotar の認証局でおきた事件の際、各ブラウザベンダは一斉にソフトウェアアップデートを行い証明書のブラックリストを配布しました。Google は、この技術を利用しブラウザが CRL 情報 (CRLset) をプッシュ配信する方式を検討している、と提案しています。ただし、Googleが全 CA の CRL を集約して配信することで、外部からの攻撃リスクの高まりや、CRL データ提供のタイムラグ等の課題もあり、今後の取り組みが注目されています。

3-3. 新たなメカニズム採用への取り組みGoogle の提案以外にも、認証局とブラウザベンダはその業界団体 CA ブラウザフォーラム新たな証明書ステータス情報確認メカニズムについて議論しています。ここでは、OCSP ステープリングと短期証明書（Short-Lived Certs）について解説します。

OCSP ステープリングOCSP の問題のひとつは、SSL ハンドシェイク時にウェブサーバとクライアント間の通信に加えて、クライアントが OSCP サーバへ通信するという実質 3 者間の通信になっておりこれが SSL ハンドシェイク時のオーバーヘッドになっていることです。OCSP ステープリングは、ウェブサーバがウェブブラウザの代わりに OSCP レスポンダに問い合わせ、SSL ハンドシェイクの際に OCSP レスポンスをクライアントに提供するというメカニズムです。※ 8 これはすでに IETF RFC6066 で定義されています。

図. OCSPステープリング

認証局（CA）

ウェブサーバ

OCSPレスポンダ

ウェブサイト利用者

SSLサーバ証明書

CRL

データベース

1. SSL ハンドシェイクOCSPレスポンス

2. SSL 通信開始

0. OCSPリクエスト OCSPレスポンス

※ 7： Adam Langlay, ImerialViolet : Revocation checking and Chrome's CRL (05 Feb 2012) http://www.imperialviolet.org/2012/02/05/crlsets.html

※ 8： CA Security Council, An Introduction to OCSP Multi-stapling, https://casecurity.org/2013/05/07/an-introduction-to-ocsp-multi-stapling/

White Paper : SSL ハンドシェイクの裏側

9

OCSP ステープリング対応しているサーバ / クライアントブラウザは決して多いとは言えませんが、これからの利用拡大が見込まれています。

対応ウェブブラウザ

Internet Explore* ○

FireFox ×

Chrome＊ ○

Opera ○

＊Windows Vista、Internet Explorer 8以降

短期証明書（Short-Lived Certs）短期証明書※ 10 は米国スタンフォード大学とカーネギーメロン大学の研究者によって提案された CRL、OCSP とは異なる考え方に基づくメカニズムです。CRL や OCSP で課題となっている通信速度の低下と運用コスト増加の問題以前に、現在の失効メカニズム自体が機能していないと指摘しています。全体の 30％以上の証明書が発行されてから 2 日以内に失効されており、現在のメカニズムではすでに失効されている証明書であっても、ウェブブラウザは SSL 通信を許してしまいます。この問題を根本的に解決するために、証明書の有効期間を 4 日間と短期間に設定し、認証局は証明書が失効していなければ新しいものを自動的に発行、サーバは常に証明書を入れ替えて運用していくという案です。彼らの論文の中では、Google が提案する CRLSet と併せて運用する方法が提案されています。

出展：Short-Lived Certs ※ 11

対応ウェブサーバ

Microsoft　IIS 7.0以上

OpenSSL　0.9.8g Apache version 2.3.3

Nginx version 1.3.7

※ 10、11： Emin Topalovic, Brennan Saeta, Lin-Shung Huangy, Collin Jacksony　and Dan Boneh, "Towards Short-Lived Certs", http:// www.w2spconf.com/2012/papers/w2sp12-final9.pdf

White Paper : SSL ハンドシェイクの裏側

10

合同会社シマンテック・ウェブサイトセキュリティhttps://www.jp.websecurity.symantec.com/〒104-0028　東京都港区赤坂1-11-44赤坂インターシティTel:0120-707-637E-mail:websales_jp@symantec.com

Copyright ©2014 Symantec Corporation. All rights reserved.シマンテック（Symantec）、ノートン（Norton）、およびチェックマークロゴ（the Checkmark Logo）は米国シマンテック・コーポレーション（Symantec Corporation）またはその関連会社の米国またはその他の国における登録商標、または、商標です。その他の名称もそれぞれの所有者による商標である可能性があります。製品の仕様と価格は、都合により予告なしに変更することがあります。本カタログの記載内容は、2014年4月現在のものです。

4．おわりに

認証局の役割は証明書を発行するだけでなく、それを運用するより安全、堅牢な PKI 基盤を提供することにあります。しかし、時に安全性の追求は利便性を損なう結果となることが少なくありません。シマンテックでは、証明書失効情報の確認といういわば裏方の作業においても、いかにユーザの利便性を損なうことなくサービスを提供できるのか、認証局単位、および業界団体単位でこの課題に挑戦しています。幅広いプラットフォームで利用されている既存の CRL、OCSP メカニズムをより迅速に、そして新鮮な情報を届けられるようサーバを増強、世界各地にアクセスポイントを分散化しレスポンススピードを向上させています。特に OCSPのパフォーマンスと信頼性は、堅牢であるとして高く評価されています。また、2013 年 2 月には米国シマンテックと 6 つのパブリック認証局が協同で CA Security Council を立ち上げ、CA ブラウザフォーラムでの活動だけでなく通信の安全を提供する認証局としてのあるべき姿を集約し、認証局の立場から課題解決に取り組み始めています。