tlsにおけるforward secrecyの利用に関する実証的研究調査

WH

ITE PA

PER

:

powered by Symantec

White Paper

TLSにおけるForward Secrecyの利用に関する実証的研究調査

Lin-Shung Huangカーネギーメロン大学[email protected]

Dan Bonehスタンフォード大学[email protected]

Shrikant Adhikarla*Microsoft社[email protected]

Collin Jacksonカーネギーメロン大学[email protected]

* カーネギーメロン大学在学中に行った調査研究。

White Paper : TLS における Forward Secrecy の利用に関する実証的研究調査

2

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

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

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


3

CONTENTS

要約 4

カテゴリと主題記述子 4

キーワード 4

1.はじめに 4

2.背景 52.1SSL/TLS 5

2.2FORWARDSECRECY 6

2.3関連のある調査研究 6

3.TLSサーバーの調査 73.1方法論 7

3.2結果 8

4.パフォーマンス分析 124.1方法論 12

4.2結果 13

5.考察 16

6.結論 17謝辞 17

7.参考文献 17


4

要約Forward Secrecy（前方秘匿性）は、盗聴者が過去に行われた暗号通信の内容を断じて解読できないことを保証するものです。Forward Secrecy をサポートするため、多くの TLSサーバーにエフェメラル Diffie-Hellman 鍵交換（DHE）が配備されていますが、その一方で、ほとんどのサイトで DHパラメータが誤設定されているため誤った安心感が生じています。合計 473,802 の TLS サイトを対象とした今回の調査で、DHE が有効になっているサーバーの 82.9% で弱い DHパラメータが使用されていることがわかりました。この調査では、サーバーとクライアントにおける Forward Secrecy のパフォーマンスインパクトを測定しました。Forward Secrecyはもはや前途多難なものではなく、むしろ（楕円曲線暗号を使用した場合）従来の RSA よりも高速となり得ることを指摘します。

カテゴリと主題記述子K.6.5 [ コンピューティングシステムと情報システムの管理 ]:セキュリティと保護

キーワードSSL、TLS、Forward Secrecy、楕円曲線暗号

1. はじめに

TLS は、インターネット上で電子メール、クレジットカード決済、個人情報といった重要な通信を保全するために一般に使用される、よく知られたセキュリティプロトコルです。クライアントが TLS サーバーに接続すると、通常は、サーバーの公開鍵によって暗号化されたワンタイムパスワードから、セッションごとのキーが導出されます。このワンタイムパスワードを復号できるのはサーバーの秘密鍵のみであるため、接続が保全されます。ただし、サーバーの秘密鍵のセキュリティは、必ずしも期待されるほど堅ろうであるとは限りません。攻撃者は、ソーシャルエンジニアリングを利用してサーバーの期限切れの（保護されているとはいえない）秘密鍵を盗み出すことができるかもしれません。あるいは、将来のスーパーコンピュータを利用して暗号解読を行うことができるかもしれません。ユーザーは今現在の暗号通信のプライバシーが TLS によって保証されることを期待しているかもしれませんが、その一方で、今現在のトラフィックを記録している盗聴者が将来的にこのトラフィックの復号に成功する可能性もあります。漏洩した文書 [5] によれば、一部の政府機関が基幹通信を記録するための監視プログラムを保持していることさえ示唆しています。政府機関がすべての暗号化ネットワークトラフィックを記録し、後でサーバーの秘密鍵を要求したとすれば、過去の暗号化トラフィックのプライバシーが危殆化しかねません。

これに対して、Google のような一部のサイトでは、Forward Secrecy[22] を配備しました。Forward Secrecy は、将来的にサーバーの秘密鍵が危殆化された場合でも、過去の通信のプライバシーを保証します。TLS サーバーは、TLS の DHE

（エフェメラル Diffie-Hellman）鍵交換方式、または ECDHE（エフェメラル楕円曲線 Diffie-Hellman）鍵交換方式を使用することで、Forward Secrecy を配備できます。これらの方法では、サーバーの長期的な秘密鍵を使用して、一時的な（エフェメラル）Diffie-Hellman 鍵交換メッセージへの署名が行われます。結果として得られる Diffie-Hellman 秘密鍵が、そのセッションのプリマスタシークレットとして使用されます。残念ながら、驚くことに今回の調査で発見されたのは、DHE を使用しているウェブサイトの 82.9% が DHE パラメータを誤設定しているため、弱いプリマスタシークレットが導出されていることです。これは、業界全体で DHE の配備方法を誤解していることを示唆しています。以下に、この問題について説明します。興味深いこととして最近 Graham は、Tor ネットワークが未だに弱い DH パラメータ [15] を使用しており、類似脅威に対して脆弱であることを明らかにしました。

調査結果。この調査では、トップ 100 万ウェブサイトを対象に、TLS サーバーの大規模なスキャンを行いました。この調査結果の一部を、以下に示します。

調査対象となったのは、TLS を使用している 473,802 のTLS サイトです。74% 以上のサイトが、少なくとも 2 つのエフェメラル鍵交換方式のいずれか一方（DHE または ECDHE）をサポートしています。残念ながら、DHE が有効になっているサーバーの 82.9% で、それぞれの RSA 鍵よりもはるかに弱い Diffie-Hellman パラメータが使用されていることが発見されました。そのため、結果として生じるセッションは、Forward Secrecy のない RSA 鍵交換が使用された場合よりもさらに、総当たり暗号解読攻撃に対して脆弱になります。

この調査では、TLS のさまざまな暗号スイートのサーバースループットを評価し、「楕円曲線ベースの Forward Secrecy」

（ECDHE）が従来の RSA よりも低速でないこと、むしろ高速であり得ることを示しました。理由は、Forward Secrecyのない RSA を用いた場合、サーバーはすべての鍵交換で計算負荷の高い RSA-2048 復号を実行しなければならないためです。ECDHE を用いた場合、サーバーはその ECDHE パラメータに一回 RSA 署名し、いくつもの接続に渡ってその署名を再利用することができます。これにより、サーバー側のオンラインでの暗号化演算は、たった 2 回の楕円曲線上の乗算となり、これは RSA-2048 の 1 回の復号よりも高速となり得ます。その結果として、Forward Secrecy のパフォーマンスに対する従来の反対論は、現行のパラメータとアルゴリズムの選択肢を前提とすれば、もはや単純に有効ではありません。この調査結果は、ウェブサイトが ECDHE の使用に移行し、セキュリティとパフォーマンスのメリットを得るべきであることを示唆しています。


5

現実世界での TLS 接続時間を測定するための最初の広告実験を 10,000 あまりのクライアント上で実施し、クライアントにとって初めての ECDSA 署名が提示されたときに起きる一時的なパフォーマンスの問題を 1 回特定しました。

本ホワイトペーパーの以降の各セクションは、次のように編成されています。セクション 2 では、背景、ならびに関連のある調査研究について述べます。セクション 3 では、人気のあるTLS サーバーの調査結果を示し、ほとんどの DHE サーバーの設定が安全でないことを明らかにします。セクション 4 では、Forward Secrecy をサポートしている一般的な TLS 暗号スイートのパフォーマンスを評価します。セクション 5 では、Forward Secrecy を配備するためのベストプラクティスについて考察します。セクション 6 では、結論を示します。

2. 背景

このセクションでは、TLS プロトコルと Forward Secrecy について簡潔に紹介します。その後、関連のある調査研究について概観します。

2.1 SSL/TLSSSL（Secure Sockets Layer）[14] の後継規格である TLS

（Transport Layer Security）[10] は、ネットワークの敵から機密情報の盗聴や改ざんを防ぎながら、クライアントとサーバーが安全に相互識別できるように設計された暗号化プロトコルです。TLS は、HTTP などのアプリケーション固有のプロトコルをカプセル化し、TCP などの基本転送プロトコル上で安全に伝送されるようにします。多くのアプリケーションで広く使用されており、ウェブメールやインターネットバンキングのサイトでは、そのほとんどで使用されています。

特に TLS は、さまざまな暗号スイートをサポートするように設計されています。TLS では、認証方法、鍵交換方式、一括暗号化方法、メッセージ認証コード（MAC）方法など、接続に使用するアルゴリズムの組み合わせを、それぞれの暗号スイートが定義します。

▪▪ 認証方法（RSA、DSA など）は、通信するピアが相互の真正性を検証できるようにし（通常は、クライアントに TLSサーバーを検証させる）、それぞれの公開鍵証明書で使用されている署名アルゴリズムと一致している必要があります。

▪▪ 鍵交換方式（RSA、Diffie-Hellman など）は、データ暗号化用のセッションキーについて、ピア同士が安全に合意できるようにします。

▪▪ バルク暗号化アルゴリズム（RC4、AESCBC など）は、アプリケーションデータを暗号化するのに使用されます。

▪▪ MAC アルゴリズム（SHA1 など）は、ブロック暗号化用メッセージダイジェストを生成するのに使用されます。

TLS には、接続を初期化する際の「ハンドシェーク」において、サーバーとクライアントがさまざまな暗号スイートを交信

（ネゴシエーション）できるようにする柔軟性が備わっています。図 1 に、従来の RSA 鍵交換を使用した、クライアント証明書を伴わない、基本的な TLS ハンドシェークを示します。最初に、クライアントが ClientHello メッセージをサーバーに送信し、サポートしている暗号スイートのリストと、クライアントのランダム変数を提供します。サーバーは、選んだ暗号スイートとサーバーのランダム変数を指定する ServerHello メッセージで応答します。暗号スイートを決定するのはサーバーであり、最終的にクライアントの優先設定をサーバーが強制変更する可能性があることに注意してください。この後、サーバーは自分の公開鍵証明書を Certificate メッセージでクライアントに送信します。クライアントはサーバーの証明書を検証して、その公開鍵が有効であり、信頼できるルート認証局（CA）が発行したものであるかどうかを確認する必要があります。この証明書を受け入れた場合、クライアントは新しいプリマスタシークレットを生成し、この生成したプリマスタシークレットをサーバーの公開鍵で暗号化し、この暗号化したシークレットをClientKeyExchange メッセージでサーバーに送信します。この時点でクライアントとサーバーは双方とも、プリマスタシークレットとワンタイムパスワードから、同じセッションキーを導出することができます。最後に、サーバーとクライアントの双方が ChangeCipherSpec メッセージを送信します。これによって、以降のメッセージが交信済みの暗号スイートとセッションキーを使用して暗号化されることを示します。

クライアントサーバー

ClientHelloServerHello

証明書ServerHelloDone

ClientKeyExchangeChangeCipherSpec完了

ChangeCipherSpec完了

図1：RSA鍵交換を使用し、クライアント証明書がない場合の、標準TLSハンドシェーク


6

2.2 Forward SecrecyForward Secrecy は、短期鍵で暗号化されたいかなるデータも将来的に、たとえ長期秘密鍵が危殆化されたとしても、盗聴者によって解読されないことを保証する、重要なセキュリティプロパティです。特に、インターネットの監視が懸念される状況において、Forward Secrecy は企業にとって、盗聴者が過去に行われた暗号通信の内容を断じて解読できないことの論拠となります。ただし TLS において、Forward Secrecy が必ずしも保証されているとは限りません。特に、（図 1 に示す）従来の RSA 鍵交換は、サーバーが自身の秘密鍵を保護できる限りにおいて、安全です。サーバーの秘密鍵が明かされてしまえば、攻撃者はサーバーの秘密鍵を使用してプリマスタシークレットを導出することにより、記録されたすべてのセッションを復号し、基本的に過去のすべてのセッションキーを回復することができます。

Forward Secrecy をサポートする TLS において、現在、鍵交換方式は 2 つあります。1 つは DHE（エフェメラル Diffie-Hellman。EDH とも呼ばれる）アルゴリズム、もう 1 つはECDHE（エフェメラル楕円曲線 Diffie-Hellman）アルゴリズムです。本質的に、これら 2 つの鍵交換方式では、（サーバーの長期秘密鍵を使用するのではなく）個別のメカニズムを使用して、破棄されたいかなるセッションキーも長期鍵では回復できないようにするという方法で、エフェメラルセッションキーを生成します。DHEまたはECDHEを使用する場合、サーバーは、プリマスタシークレットの導出に使用されるサーバーパラメータを動的に生成し、これらのサーバーパラメータをTLS ハンドシェーク時に、もう1 つの ServerKeyExchangeメッセージで（Certificate メッセージの後）、クライアントに送信します。たとえば、RSA 署名を用いて DHE 鍵交換を使用する場合、ServerKeyExchange メッセージには、サーバーの RSA 秘密鍵で署名された DHE（エフェメラル Diffie-Hellman）公開鍵が含まれます。同様に、RSA 署名を用いてECDHE を使用する場合、ServerKeyExchange メッセージには、ECDHE（エフェメラル楕円曲線 Diffie-Hellman）公開鍵と、その楕円曲線ドメインパラメータが含まれ、これらはともにサーバーの RSA 秘密鍵で署名されます。サーバーは、ECDSA 秘密鍵で ECDHE 公開鍵に署名することによって、RSA 署名全体を楕円曲線暗号で置き換えることも可能です。

2.3 関連のある調査研究セキュリティの脆弱性を検出するため、大量の TLS サーバーをスキャンする調査がいくつか行われてきました [30、35、23、

29]。2002 年、Rescorla[30] は、OpenSSL のリモートバッファオーバーフローバグに対して脆弱なサーバーを検出するため、891 台のサーバーをスキャンしました。2008 年、Yilek およびその他 [35] は、Debian OpenSSL の乱数度の脆弱性に

よる影響を受けたサーバーを検出するため、50,000 台以上の TLS に対する日単位のスキャンを実施しました。2006 年、Lee およびその他 [23] は、19,429 台の TLS サーバーをスキャンし、弱いエクスポート暗号と安全でないプロトコルバージョンに対するサポート状況をチェックするとともに、経時的な暗号化アルゴリズムの採用についても報告しています。この時点では、TLS サイトの 85% が安全でない SSLv2 プロトコルをサポートしていました。同様に、SSL Pulse[29] は、安全でない暗号スイート、安全でない再交信、BEAST 攻撃、ならびに CRIME 攻撃に対して脆弱なサイトを検出するため、およそ 200,000 台の TLS サーバーをスキャンしています。比較すると、今回の TLS に関する調査は、より大規模なデータセットに対して実施しており、サーバーの ECDHE パラメータと DH パラメータに関する詳細をさらに明らかにしています。セクション 3.2 で、さまざまな暗号化アルゴリズムとプロトコルに関するサポートについて、今回の調査結果を、Lee およびその他による調査と比較します。

TLS に関する別のカテゴリの調査 [13、17、3、12] では、証明書分析に焦点が当てられています。EFF SSL 観測プロジェクト [13] では、TLS 接続を受け入れた 1080 万の IP アドレスに渡り、130 万の異なる証明書を収集したところ、1,482もの信頼済み証明書署名者が現実世界で発見されています。Holz およびその他 [17] は、Alexa のトップ 100 万サイトのスキャン、ドイツ研究ネットワークの TLSトラフィックの監視など、X.509 公開鍵インフラストラクチャの包括的な測定を 1年半に渡り実施し、観測された証明書の約 40% は、期限切れ、不正なホスト名、信頼できない署名者といった誤設定により、検証されないであろうことを明らかにしました。2012 年には、Akhaweおよびその他による同様の調査 [3]で30万ユーザーの TLSトラフィックが監視され、証明書警告の原因がさらに、サーバーの誤設定（チェーン検証エラー、名前検証エラーを含む）と、ブラウザの設計決定（失効など）にカテゴリ分けされています。Durumeric およびその他による最近の調査 [12] では、1 億 900 万台のホストで使用される 4,240 万の重複のない証明書に対する徹底的なスキャンが 14 カ月に渡って実行され、1,832 の信頼済み署名証明書が特定されました。今回の調査は、証明書の分析を行うことが目的ではなく、DHE 鍵交換のサーバーの誤設定を見つけることに焦点を合わせているという点で、上記調査とは異なります。セクション3.2 で、公開鍵長の分布を、Durumeric およびその他による証明書分析から導かれる結果と比較します。これらの公開論文とデータに加え、多数のオープンソースの TLS スキャンツール

（SLyze[19]、TLS Prober[28]、SSLScan[33] など）を発見しました。


7

TLS のパフォーマンス評価は、過去に多数 [4, 9, 16, 6, 24] 実施されています。2002 年には、Coarfa およびその他 [9] が、トレース駆動の作業負荷と、TLS の各処理段階で測定された個々のコスト（計算負荷）を用いて、TLS ウェブサーバーをプロファイルしており、TLS ウェブサーバーにおける最大のパフォーマンスコストが RSA 演算であることを示す一方、CPUが高速になるにつれ TLS オーバーヘッドは縮小するであろうことを示唆しています。Guptaおよびその他による調査 [16]では、RSA 署名に比べ ECDSA 署名を使用した場合、TLS サーバーのスループットが 11% ないし 31% 増加する可能性があることを示しています。さらに、RSA を上回る ECDSA のパフォーマンスの強みは、鍵の強度が強まるにつれ、さらに増幅します。ただし、これらの調査では、Forward Secrecy を提供する暗号スイートの影響を評価しませんでした。Bernat による論文 [6] では、RSA、DHE、ECDHE のそれぞれの鍵交換における 1,000 ハンドシェークのパフォーマンスを比較しており、ECDHE を使用した場合の Forward Secrecy のコストは、RSA を上回ることわずか 15% であることを示しています。同様に、Mavrogiannopoulos[24] が実行したマイクロベンチマークでは、192-bit ECDSA 鍵を用いた ECDHE の方が、1776-bit RSA 鍵交換よりも優れたパフォーマンスを示しました。今回の調査ではさらに、Forward Secrecy を提供する 4 種類の暗号スイートのサーバースループットを、現在推奨されている 2048-bit RSA、2048-bit DSA、256-bit ECDSA の各署名との組み合わせで評価します。加えて、現実世界でクライアントが受ける TLS 遅延を測定する試みとして、今回の調査で初めて広告実験を実施しています。

3. TLS サーバーの調査

このセクションでは、選り抜きの TLS サーバーを調査し、Forward Secrecy をサポートしているサーバーの数がどの程度あるか、また DH パラメータを誤設定しているサーバーがないかどうかを考察します。最初に、ウェブサイトをスキャンするための方法論を述べます。その後、今回の調査結果を示すとともに考察します。

3.1 方法論調査は、トップ 100 万グローバルサイト（2013 年 9 月 9 日に Alexa[1] から取得）を対象に、2013 年 9 月 13 日から2013年9月27日までの間に行いました。Alexaのデータセットは、インターネット上の人気サイトを過不足なく網羅することで知られており、既存のいくつもの TLS サーバー調査で使用されています [23, 17, 12]。ただし、Alexa のランキングは TLSトラフィックに基づくものではないため、リストされたサイトの多くがまったくTLS をサポートしていません。そこで、単純化したヒューリスティックを使用して、TLS サーバーの検出を行

いました。

1. https://{HOSTNAME}:443 への接続を試みる。エラーが発生した場合は、ステップ 2 進む。このデータセット内のホスト名の大多数は、ネイキッドドメインであることに注意する。

2. https://www.{HOSTNAME}:443 への接続を試みる。（反対に、www で始まるホスト名の場合は、ネイキッドドメインへの接続を試みる。）

「login」、「signin」、「secure」、「mail」のような、よく使用されるサブドメインをスキャンすることによって、より多くのTLS サーバーを検出することも可能ではありますが、ただでさえ大量のデータセットであるため、待ち受けページを調査することに焦点を合わせました。

この調査では、多数のウェブサイトを効率的にスキャンするため、既存の SSLScan 1.8.2[33] に基づく、独自の TLS スキャンツールを実装しました。SSLScan は、基本的にホストに対して複数の TLS 接続を行うことで（接続ごとに異なる設定が使用される）、1）サポートされるプロトコルバージョン、2）サポートされる暗号スイート、3）TLS サーバーのデフォルトの暗号スイートを判定します。今回の調査では、より新しいプロトコルバージョン（TLSv1.1 と TLSv1.2）を検出するように SSLScan を修正しました。さらに、サーバーが提供する実際の DHE パラメータや ECDHE パラメータなど、より詳しい接続情報を明らかにするため、修正済み OpenSSL 1.0.1eライブラリ [32] をプログラムに統合しました。

このスキャンプロセスは主に、ネットワーク遅延に起因する I/O境界であるため、並列で動作する複数のスキャナを管理する多重処理用 Python ラッパーを実装して、データセット全体の総スキャン時間を削減しました。ソケット接続のタイムアウトを30 秒に設定しました。

各ホストに対して、合計 460 回の異なる TLS 接続を行いました。詳細は以下のとおりです（すべて OpenSSL 1.0.1eで入手できるものです）:SSLv2 を使用する暗号スイート 7種類、SSLv3 を使用する暗号スイート 112 種類、TLSv1を使用する暗号スイート 112 種類、TLSv1.1 を使用する暗号スイート 112 種類、TLSv1.2 を使用する暗号スイート112 種類、さらに各プロトコルバージョンのデフォルトの暗号スイートを判定するための接続が 5 回。

TLS 証明書の検証作業は、いくつもの既存の調査 [17, 3, 12, 13]

で研究されているため、今回の調査では行っていません。


8

3.2 結果トップ 100 万ウェブサイトのうち 473,802 台の重複のないホストに対して TLS スキャンを正常に実行しました。異なるホスト名で同じIP または物理マシンを共有している可能性がある

（一般に仮想ホスティングと呼ばれる）ことに注意してください。

まず第一に、ネイキッドドメインと www サブドメインが両方とも失敗した 526,198 件の Alexa エントリについて、接続エラーの概略を表 1 に示します※ 1。接続エラーのほとんど（例 : タイムアウト、接続が拒否された、接続リセット）は、単純に、ウェブサイトで TLS サーバーがポート 443 で実行されなかったためです。SSLエラーはおそらく、サーバーの誤設定により、TLS ハンドシェークが完了する前に警告メッセージがトリガされたことが原因です。無効なホスト名エラーのほとんどは、ホスト名のストリングに不正な URL パスコンポーネントが含まれていたことが原因です。

表1:接続エラー

エラーホスト

接続が拒否されたエラー 163,948

SSL エラー 187,532

タイムアウト 120,068

無効なホスト名エラー 41,209

接続リセットエラー 11,915

IP 到達不能 1,325

DoS ブロック 192

その他のエラー 9

「DoS ブロック」という分類のエラーが 192 件ありました。これは、サイトが実際に初期 TLS 接続を受け入れたものの、テストの途中で（セクション 3.1 に述べた 460 回の TLS 接続中）、実験用マシンへの応答を完全に停止したことを意味します。理由としては、これらのウェブサイトが DoS 防御を配備しており、我々の高速接続後に、我々のマシンをブロックしたことが考えられます。これに対しては回避方法があるかもしれませんが（たとえば、より多くの IP を利用する、接続レートを低くする）、サイトの数が顕著ではありませんでした。

3.2.1プロトコルバージョン表 2 に示すのは、それぞれの SSL/TLS プロトコルバージョンをサポートしている重複のないホストの割合です（TLS スキャンを完了した 473,802 の重複のないホストのうち）。重複のないホストのそれぞれが複数のプロトコルバージョンをサポートしている可能性があります。2006 年 11 月の Lee およびその他による調査 [23] と比べると、最も顕著な差異は、

SSLv2 へのサポートが 85% から 22% まで一気に減少している一方で、TLSv1.1 と TLSv1.2 の採用がゆるやかに増えていることです。TLS の採用に関する今回の調査結果は、2013 年 8 月の SSL Pulse による調査 [29] とおおむね一致しています。ただし、TLS サイト 473,802 件という今回のデータセットの方が、規模としては上回っています。

表2:プロトコルのバージョンのサポート

バージョンホスト SSLPulsea

IMC'07b

SSLv2 105,239 (22.2%）

26.9% 85.37%

SSLv3 470,409 (99.2%）

99.7% 97.92%

TLSv1 471,458 (99.5%）

99.3% 98.36%

TLSv1.1 79,890 (16.8%） 15.4%

TLSv1.2 84,406 (17.8%） 17.8%

a SSL Labs[29]による 168,088 サイトを対象とする調査 (2013 年 8 月現在）。

b Lee およびその他[23]による 19,429 サイトを対象とする調査 (2006 年 11 月現在）。

3.2.2認証表 3 に、それぞれの認証方法をサポートする重複のないホストの割合の比較を示します。重複のないホストのそれぞれが、交信済み暗号スイートに従って異なる TLS 証明書を提供することで、複数の認証方法をサポートしている可能性があります。いずれか（すべてである必要はない）のプロトコルバージョンを使用するホストが、ある特定の認証方法を受け入れた場合、その認証方法はサポートされていると見なします。

表3:認証方法のサポート

方式ホスト IMC'07

RSA 473,780 (99.9%）

≥ 99.86%a

匿名 7,750 (1.6%）

DSA 22 (0.0%） 0.02%

ECDSA 2

ECDH 1

a 認証と鍵交換の両方に RSA が使用されていることを示す割合。

ここに示すように、圧倒的に RSA が最も一般的に配備されている認証方法です。この結果は、2006 年 [23] 以来、大きく変わってはいません。ECDSA 認証をサポートしている 2 台のホストのみを観察しました。手動検査により、一方のホストは自己署名 ECC 証明書を使用し、他方のホストは Symantec Class 3 ECC 256 bit Extended Validation CA により署名された有効な ECC 証明書を使用していることが観察され

※ 1：ネイキッドドメインと www サブドメインで異なるエラーが発生していた場合は、（Alexa データセットにある）元のホスト名のエラーを示しています。


9

ました。ECDH 認証（なおかつ自己署名証明書）を使用して固定型 ECDH 鍵交換をサポートしている、奇妙なホストが 1台ありました。残念ながら、1.6% のホストが依然として匿名の暗号スイートをサポートしていることが判明しました。こうしたホストは、いかなる認証も提供せず、TLS 中間者攻撃に対して脆弱であることが自明です。

次に、表 4 に示す、各 RSA 公開鍵サイズ（またはサイズ範囲）をサポートする重複のないホストの割合を見ることにします。重複のないホストのそれぞれが複数の公開鍵サイズをサポートしている可能性があることに、注意してください。Durumeric およびその他によって公開された割合 [12] は、異なる方法で計算されています。重複のないホストではなく、重複のない信頼できる証明書をカウントすることによって、各公開鍵サイズの分布を表しており、さらに、（ブラウザによって）信頼されない証明書を除外しています。そのため、今回の調査結果との差異があることが考えられます。とはいえ、今回の調査結果が彼らの調査結果とおおむね一致していることがわかりました。1024 ビットの RSA 公開鍵の使用状況が 2006年の 88.35%[23] から大幅に下落している一方、2048 ビットの公開鍵が今やほとんどの TLS ウェブサイトでサポートされています。

表4:RSA公開鍵サイズ( ビット）のサポート

サイズホスト IMC'13a IMC'07

≤ 512 350 (0.0%） 0.1% 3.94%

513 - 1023 20 (0.0%） 0.0% 1.42%

1024 87,760 (18.5%）

10.5% 88.35%

1025 - 2047 20 (0.0%） 0.7% 0.01%

2048 374,294 (79.0%）

86.4% 6.14%

2049 - 4095 251 (0.0%） 0.0% 0.00%

4096 11,093 (2.3%） 2.3% 0.19%

≥ 4097 22 (0.0%） 0.0% 0.00%a Durumeric およびその他 [12] により、2140 万台のホストにおいて 320

万の重複のない信頼済み証明書が記録された (2013 年 3 月）。

3.2.3鍵交換表 5 に、それぞれの鍵交換方式をサポートする重複のないホストの割合を示します。現在のところ、RSA が最も広くサポートされている鍵交換の方法です。TLS サイトの59.8% で DHE がサポートされており、これは 2006 年の57.5%[23] から辛うじて増加しています。ECDHE をサポートしているのは、TLS サイトのわずか 17.9% です。DHEまたは ECDHE をサポートしている重複のないホストは、合計 353,209 台（74.5%）でした。前述のとおり、DHE とECDHE は Forward Secrecy をサポートしますが、RSA はサポートしません。Forward Secrecy をサポートするサーバーのうち、重複のない 287,301 台のホスト（サポートサーバーの 81%）が、デフォルトでは DHE または ECDHE を使

用することを選びました。

表5:鍵交換方式のサポート

方式ホスト IMC'07

RSA 473,688 (99.9%） 99.86%

エフェメラル DH 283,647 (59.8%） 57.57%

エフェメラル ECDH 85,070 (17.9%）

固定型 ECDH 1 (0.0%）

誤設定されているエフェメラルDHパラメータ。もう一歩進んで、エフェメラル Diffie-Hellman 鍵交換をサポートしているサーバーの実装を、エフェメラル DH パラメータのサイズのログをとることによって観察します（表 6）。残念ながら、DHE が有効になっているサーバーの 99.3% が 1024ビットのDHパラメータをサポートしていることがわかりました。CA とブラウザが 2013 年末までに（CA/ ブラウザフォーラムによる基準勧告 [8] に従い）2048 ビットの RSA 認証（すなわち、より強い認証）に移行している中、これは安全でないと考えられます。DHE が有効になっているサーバーのうち、実際に 2048 ビットの DH パラメータを配備しているのは、わずか 0.3% です。

表6:DHパラメータサイズ( ビット）のサポート

サイズホスト

1024 281714 (99.3%）

512 96,559 (34.0%）

768 933 (0.3%）

2048 859 (0.3%）

4096 14 (0.0%）

3248 2 (0.0%）

256 2 (0.0%）

1544 1 (0.0%）

表 7 に示すのは、エフェメラル DH パラメータのサイズが、実際にはその署名サイズよりも小さい（弱い）サイズに設定されている、重複のないホストの割合です。ここに示すとおり、DHE が有効になっているサーバーの大多数（82.9%）が、より小さい DH パラメータを提供していました。こうした誤設定されたホストの 61.9% で、DHE 鍵交換がそのサーバーのデフォルトの暗号スイートでした。本質的にこれは、デフォルトではそのセキュリティを弱めることになります。DHE が有効になっているサーバーの 33.9% が「エクスポート」の暗号スイートを使用していることがわかりました。エクスポート暗号は、意図的に安全でない作りとなっており、署名サイズに関係なく、DHE 鍵交換に 512 ビットの DH パラメータを使用するにすぎません。


10

表7:DHパラメータのサイズが署名のサイズよりも小さかった、DHE- が有効になっているサーバーの数

方式ホスト

すべてが誤設定されているサイト 235,297 (82.9%）

DHE がデフォルトで使用されている 175,709 (61.9%）

「エクスポート」暗号スイート 96,338 (33.9%）

エフェメラルECDHパラメータ。励みは、成功した全 ECDHE 接続のうち、RSA 署名よりも弱いエフェメラル ECDHE 鍵が 1 つもなかったことです。表8 に、ECDHE が有効になっているサーバーで実際に使用された楕円曲線の名前の一覧を示します。すべて米国商務省標準化技術研究所（NIST）により承認済みのものです [27]。ECDHE が有効になっているサイトの大半で使用されている曲線は secp256r1 であり、これは NIST P-256 とも呼ばれています。今回の調査では、任意の明示的な曲線（RFC 4492[7] で許可されている）を使用している実装は、観察しませんでした。

表8:ECDH曲線のサポート

曲線ホスト

secp256r1 81,789 (96.1%）

sect233r1 3,123 (3.6%）

sect571r1 316 (0.3%）

secp384r1 86 (0.1%）

secp521r1 73 (0.0%）

sect163r2 26 (0.0%）

secp224r1 3 (0.0%）

secp192r1 1 (0.0%）

スキャン中、接続ごとの ECDHE 公開鍵のログもとりました。その結果、34,145 台のホスト（ECDHE が有効になっているサーバーの 40.1%）が、それぞれの ECDHE 公開鍵を、異なる接続に対して再使用していることを観察しました。これは、これらのサーバーが、新規接続のたびには ECDHE パラメータへの再署名を行わなかったことを意味します（再署名すると、計算負荷が高くなります）。これは、サーバーがECDHE公開鍵を定期的に再生成する限りは、安全です。他方、ECDHE が有効になっているその他のサーバーは、ECDHE公開鍵を再生成する頻度が高すぎるのかもしれません。今回の調査で行ったそれぞれ異なる接続は、個々の TLS サーバーに対して負荷分散がなされ、その結果、クライアントにとって異なる ECDSA パラメータとして見えた可能性があるため、ここでの観察が最終結論ではありません。

3.2.4暗号化表 9 に、それぞれの暗号方式と鍵サイズをサポートする重複のないホストの割合の比較を示します。それぞれの列に、全プロトコルバージョンを含んだ場合の割合と、TLSv1.2 のみを使用した場合の割合を示します。

表9:暗号方式のサポート

方式ホスト TLSv1.2a IMC'07

3DES-168 446,119 (94.1%）

81,085 (96.0%）

97.50%

RC4-128 436,994 (92.2%）

77,271 (91.5%）

98.58%

AES-256 428,176 (90.3%）

82,191 (97.3%）

56.37%

AES-128 428,011 (90.3%）

82,420 (97.6%）

2.05%

DES-56 153,243 (32.3%）

10,400 (12.3%）

62.29%

Camellia-128 150,421 (31.7%）

26,656 (31.5%）

Camellia-256 150,443 (31.7%）

26,637 (31.5%）

RC4-40 127,209 (26.8%）

7,725 (9.1%） 91.75%

RC2-40 124,890 (26.3%）

7,677 (9.0%） 90.31%

DES-40 114,036 (24.0%）

7,715 (9.1%） 66.55%

SEED-128 85,272 (17.9%）

16,837 (19.9%）

RC2-128 81,570 (17.2%）

0 (0.0%） 83.78%

AES-GCM-128

56,098 (11.8%）

56,098 (66.5%）

AES-GCM-256

55,614 (11.7%）

55,614 (66.5%）

IDEA-128 37,735 (7.9%） 8,807 (10.4%）

Null 443 (0.0%） 30 (0.0%）a この列に示す結果は TLSv1.2 の場合のみ。

総合的な割合では、3DES が現在のところ最もサポートされている暗号であることが観察されています。鍵サイズは 168ビットですが、効果的なセキュリティはたった 112 ビットであることがよく知られており、従って、もはや推奨されないことに注意してください。128 ビット以上で最も一般的にサポートされている暗号は RC4 と AES で、どちらも 90% 以上で採用されています。興味深いことに、256 ビット AES は採用率で 128 ビット AES に劣っていません。

2006 年の調査 [23] と比較すると、AES-128 の採用が2.05% から 90.3% へと劇的に増加していることがわかります。また、DES や RC2 などの旧式暗号に対するサポートが大幅に減少していることがわかります。


11

弱い暗号。残念ながら、全 TLS サイトの 1/3 が依然として、安全でないと考えられる DES-56 をサポートしています。おおまかに、全 TLS サイトの 1/4 が 40 ビット暗号（RC4-40、RC2-40、DES-40 など）をサポートしています。443 のサイトがnull 暗号さえもサポートしていることがわかりました。言い換えれば、重要なデータを平文で送信しています。こうした安全でない暗号スイートは、テストのみを目的として設定されている可能性もあります。とはいえ、ウェブサイト側で理解しておく必要があるのは、弱い暗号が有効になっている限り、ネットワーク攻撃者はサポートされている暗号のうち最も弱い暗号を被害者が使用するように仕向けることが可能であるということです（たとえそれがデフォルトの暗号でない場合であっても）。

TLSv1.2 暗号。次に、特に TLSv1.2 を使用する暗号方式をサポートしている重複のないホストの数を比較します（表 9）。TLSv1.2 以降でサポートされた新しい暗号、AES ガロアカウンターモード

（AES-GCM）が、全 TLSv1.2 サイトの 66.5% で有効になっていることが観察されます。AES-GCM は、BEAST[11]

のような暗号文ブロック連鎖モードの脆弱性に対する免疫です。TLSv1.2 を使用する場合、40 ビット暗号や 56 ビット暗号のサポートの割合が低いこともわかります。ウェブサイトは3DES、RC4、AES-CBC をやめて、AES-GCM を採用すべきであることが推奨されます。

3.2.5MAC表 10 に、ウェブサイトでの各種 MAC 方式のサポートを示します。SHA1 が広く（99.9%）サポートされている一方、MD5 のサポートは前回 2006 年の調査 [23] 以来、99.83%から 72.3% に減少しています。ここで、認証付暗号化方式

（AEAD）とは、ハッシュベースの MAC を別に実行するのではなく、（AES-GCM などの新しいブロック暗号用に）単一の鍵でメッセージの暗号化と認証を行う方式です。

表10:MAC方式のサポート

方式ホスト IMC'07SHA1 473,462

(99.9%）99.47%

MD5 342,618 (72.3%）

99.83%

SHA256 69,266 (14.6%）AEAD 56,200 (11.8%）SHA384 40,915 (8.6%）

3.2.6デフォルトの暗号スイート最後に、重複のない 473,802 台のホストのデフォルトの暗号を見ることにします。デフォルトの暗号スイートとは、クライアントがすべての暗号スイートをサポートしている場合に、サーバーによって交信（ネゴシエーション）される暗号スイートです。表 11 に、各プロトコルバージョンで最も一般的なデフォルトの暗号スイートの上位 3 つを示します。重複のないホストのそれぞれが、各プロトコルバージョンに対して異なるデフォルト暗号スイートを持っている可能性があることに、注意してください。ここで、個々の TLS クライアントによる暗号スイートのサポートは考慮していません。

表11:各プロトコルバージョンで最も一般的なデフォルトの暗号スイート

バージョン暗号スイートホスト.SSLv2 DES-CBC3-MD5 103,264 (98.1%）

RC4-MD5 340 (0.3%）IDEA-CBC-MD5 22 (0.0%）

SSLv3 DHE-RSA-AES256-SHA 237,472 (50.4%）RC4-SHA 111,814 (23.7%）AES256-SHA 42,636 (9.0%）

TLSv1 DHE-RSA-AES256-SHA 237,210 (50.3%）RC4-SHA 83,101 (17.6%）AES256-SHA 42,892 (9.0%）

TLSv1.1 ECDHE-RSA-RC4-SHA 32,354 (40.4%）RC4-SHA 14,528 (18.1%）DHE-RSA-AES256-SHA 12,531 (15.6%）

TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256

30,196 (35.7%）

DHE-RSA-AES256-GCM-SHA384

12,524 (14.8%）

AES256-SHA 11,922 (14.1%）

おおまかに、SSLv3 サイトと TLSv1 サイトの半数で、従来の RSA 鍵交換よりも DHE 鍵交換（Forward Secrecy をサポートする）が好まれています。ECDHE 鍵交換（これもForward Secrecy をサポートする）は、TLSv1.1 サイトの40.4%、TLSv1.2 サイトの 35.7% で好まれています。多くのウェブサイトが（非推奨の SSLv2 の使用は例外として）実際に Forward Secrecy を好んでいることがわかるのは励みになる一方、ネットワーク攻撃者が常に、サポートされている暗号スイートのうち最も弱い暗号スイートを選択できること、あるいは可能な場合にはプロトコルバージョンをダウングレードさえできることに慎重であるべきです。そのためウェブサイトでは、安全でない暗号スイートは、デフォルトであるかどうかに関係なく、完全に無効にすべきです。


12

4. パフォーマンス分析

前のセクションで、DHE 実装の 82.9% が安全でない一方、ECDHE はこれをサポートしているすべてのホストで正常に設定されていたことを明らかにしました。ECDHE がさほど広く配備されていない理由をさらに理解するため、今回の調査では、Forward Secrecy をサポートする各種暗号スイートのパフォーマンスの比較実験を行っています。

4.1 方法論TLS の暗号スイートのパフォーマンスを評価するため、2 種類の実験を実施しました。1 つは制御実験で、高速ネットワークの各サーバーに対して負荷テストを行いました。もう1 つは広告実験で、現実世界のクライアント上での TLS 接続時間を測定しました。

サーバーのセットアップ。今回の実験では、OpenSSL 1.0.1e でコンパイルしたApache HTTP サーバ 2.4.4 を使用して、我々の TLS サーバーを実行しました。DHE 暗号スイートの 2048-bit Diffie-Hellman パラメータを有効にするため、Abalea による mod ssl のパッチ [2] を適用しました。コンパイルフラグには、Käsper およびその他による楕円曲線の最適化実装 [21] を行うため、OpenSSL の enable-ec_nistp_64_gcc_128 を使用しました。サーバーには、Debian Linux 2.6.32-5 を実行し、AMD Opteron 4170 HE 2.1 GHz CPU, 512 MB RAM を搭載し、ネットワーク帯域幅が 40 Mbps の、Rackspace 社のクラウドサーバーを使用しました。

評価する TLS 暗号スイートとして、次の 5 種類を選びました :（1）RSA-RSA:RSA 鍵交換と RSA 署名、（2）DHE-RSA:DHE 鍵交換と RSA 署名、（3）ECDHE-RSA:ECDHE 鍵交換と RSA 署名、（4）ECDHE-ECDSA:ECDHE 鍵交換と ECDSA 署名、（5）DHE-DSA:DHE 鍵交換と DSA 署名。この実験の暗号スイートはすべて、暗号化に AES-128、MAC に SHA1 を使用するように設定しました。複数の TLS 仮想ホストをそれぞれ異なるポートにセットアップし、それぞれの TLS 仮想ホストを、単一の暗号スイートのみを許可するように設定しました。

TLS サーバーでは以下の 3 つの実働環境の証明書チェーンを使用しました。すべて、シマンテック社が発行したものです。RSA 署名を使用する 3 種類の暗号スイートには、RSA 2048-bit ルート証明書、RSA 2048-bit 中間証明書、RSA 2048-bit リーフ証明書から成る TLS 証明書チェーンを使用しました。DSA 署名には、DSA 2048-bit ルート証明書、DSA 2048-bit 中間証明書、DSA 2048-bit リー

フ証明書から成る証明書チェーンを使用しました。ECDSA 署名には、ECDSA 384-bit ルート証明書、ECDSA 256-bit 中間証明書、ECDSA 256-bit リーフ証明書から成る証明書チェーンを使用しました。リーフ証明書にはすべて、SHA256 の署名ハッシュを使用しました。ルート証明書と中間証明書には、シマンテック社では、RSA には SHA1、DSA には SHA256、ECDSA には SHA384 を使用しました。

ウェブページの複雑性によって TLS サーバーのパフォーマンスが異なる可能性があるため、インターネット上の実際のウェブサイトからミラー化した 3 種類のウェブページを、実験用にセットアップしました。

▪▪ 単純なページ。この調査の著者の 1 人が所有するホームページのコピー。このページは静的で、単一ドメインでホストされています。

▪▪ 複雑なページ。Amazon.com の待ち受けページ。このページを、サブリソース（画像、スタイルシート、スクリプトなど）と共にダウンロードし、このページとすべてのサブリソースを単一のドメインでホストしました。

▪▪ マルチドメインページ。Salon.com の待ち受けページ。このページは、ダウンロード後、そのサブリソースを元のドメインに従って手動でカテゴリ分けしました。その後、サブリソースを提供するため、（元のドメインに従って）10個のサブドメインを我々のサイトにセットアップし、これらのサブドメインにあるサブリソースを要求するように待ち受けページを修正しました。

4.1.1制御実験制御実験では、さまざまなサーバー構成における最大サーバースループットの測定を試みています。これらの測定を実行するため、40 Mbps のプライベートネットワークを介して接続された複数のクライアントを使用し、実験用サーバーに向けて合成 TLSトラフィックを生成しました。同時 HTTPS 要求を繰り返し発行するため、Apache の ab ツール [31]（OpenSSLベース）を使用しました。クライアントから出されるトラフィックの負荷を徐々に上げていきながら、サーバーの使用状況を手動で監視し、これをサーバーのスループットが一貫した飽和状態に達するまで続けました。その後、このサーバーのスループットを平均 5 分間にわたって測定します。健全性検査として、各サーバー構成を個別に 2 回テスト（1 回目は GET 要求を使用し、その後 HEAD 要求を使用）しました。この実験を 30 回繰り返しました。すなわち、セクション 4.1 で述べた3 種類のウェブページと5 種類の暗号スイートのそれぞれに対して、2 種類の HTTPS 要求を使用しました。

※2：リッチメディア広告キャンペーンを対象として実験を行う手法は、以前の研究[20、18]と同様です。


13

4.1.2広告実験各種暗号スイートの使用における SSL セットアップ時間を比較するため、今回の測定を現実世界のクライアント上で行うための広告実験を実施しています※ 2。広告ネットワーク上にある、世界中の何千ものブラウザに対して、測定コードを提供しました。この実験は 2 台のマシンから成ります。1 台は TLS サーバーを実行するマシンで、（セクション 4.1 に記載されているとおり）複数の仮想ホストをそれぞれ異なるポートにセットアップしたものです。もう1 台は、実験用の広告ページ（測定コードを含む）をホストする Apache サーバーを個別に実行するマシンであり、同時にログサーバーとしても機能します。実験用広告はユーザーの介入を必要とせず、クライアント上で以下のタスクを実行するように設計されています。

▪▪ 実験用広告ページが、テストページを IFRAME にロードすることによって、複数の TLS テストポートのそれぞれに対して（各種暗号スイートを使用して）TLS 接続をオープンします。各種暗号スイートは順次、1 秒間の遅延を挟んで、順不同でテストされます。

▪▪ 各テストページの中で、HTML5 の Navigation Timing API[34] を使用してページロードの待ち時間を収集し、このデータを postMessage を使用して実験用広告ページに送信します。

▪▪ 最後に、すべてのテストが完了した場合は、実験用広告ページが集計済みデータをログサーバーに送信します。

各クライアントの処理能力とネットワーク接続性が著しく異なる可能性があるため、一部のクライアントに異なるタスクを割り当てるのではなく、すべてのクライアントに対して全暗号スイートをテストするように指示しています。すべてのテストが完了する前にユーザーが実験用広告から去った場合（またはブラウザの当該タブを閉じた場合）は、実行用コードは、いかなるデータも報告しません。テスト中に並行して起こり得る他のページロードアクティビティの偏りを小さくするため、テストの順序は、意図的に無作為としました。たとえば、最初のいくつかのテストを実行している間に、（実験用広告が埋め込まれている）ホストサイトの一部の初期化スクリプトがバックグラウンドで実行される可能性があり、この場合、一部のテストがスローダウンします。

以下の4つのTLS暗号スイートをテストすることができました:（1）RSA-RSA、（2）DHE-RSA ※ 3、（3）ECDHE-RSA、（4）ECDHE-ECDSA。2048-bit DSA 署名をサポートする主要なブラウザが現在のところ 1 つもないという事実により、DHE-DSA はテストから除外する必要がありました。

我々は、HTML5 の Navigation Timing API が今回の実験の重要な構成要素であることを認識しています。Navigation Timing API は、細かいページロードイベント（DNS ルックアップ時間、SSL セットアップ時間など）について、より正確なタイミング測定ができるように設計されたもので、JavaScriptの Date オブジェクトでページロード全体の時間を測定するのとは対照的です。今回の実験結果では、以下のメトリクスを使用することができました。

▪▪ SSL セットアップ時間 : クライアントがサーバーとの SSL ハンドシェークを開始してから、接続が確立されるまでの時間。

▪▪ サーバー接続時間 : クライアントがサーバーとのソケット接続を開始してから、接続が確立されるまでの時間。これには、TCPハンドシェークと SSL ハンドシェークの両方が含まれます。

▪▪ サーバー応答時間 : クライアントが HTTPS 要求を送信してから、クライアントがサーバーからの応答の第 1 バイトを受信するまでの時間。

残念ながら、Nav igat ion T iming API のsecureConnectionStart 属性（HTTPS ページの SSL セットアップ時間を提供する）は、仕様でオプションとして定義されており [34]、本調査時点では Chrome ブラウザのみで利用可能でした。

4.2 結果このセクションでは、最初に、制御実験から得られたサーバーのスループットを提示し、その後、広告実験から得られたクライアント側の TLS 接続時間を提示します。

4.2.1サーバーのスループット完全に負荷がかかっているときにウェブサーバーが提供できる要求の最大レートを測定するため、それぞれのサーバー構成を過剰な HTTPSトラフィック下に置きました。図 2 に、それぞれのサーバー構成について、GET 要求と HEAD 要求によって完全に負荷がかかったときのサーバーのスループットの平均を示します。

最初に、GET 要求下にあるサーバーのスループットに対する鍵交換方式（すなわち RSA、DHE、ECDHE）の影響を観察します。RSA 署名を等しく使用した 3 種類の暗号スイートを比較することで、RSA-RSA が明らかに 3 種類の中で最速であることがわかりました。単純なページを提供する場合は、秒あたり265.4 要求となっています。DHE-RSA の場合は、RSA-RSA と比べ、全ページに渡ってサーバーのスループットが著しく減少しています。（せいぜい、平均で秒あたり45.7

※ 3： DHE-RSA は、現在 Internet Explorer ではサポートされていませんが、Chrome で測定することができました。


14

要求となっています）。これは、エフェメラル DH 鍵を生成するための余分な計算と、余分なハンドシェークメッセージによるものと考えられます。さらに、ECDHE-RSA の結果（単純なページを提供する場合に最大で秒あたり237 要求）は、Forward Secrecy のためのサーバースループットの損失がDHE-RSA に比べはるかに目立たないものであることを示しています。

次に、サーバーのスループットに対する署名アルゴリズムの影響を見ます。DHE-RSA と DHE-DSA を比較することで、結果が同様であることがわかります。DHE-RSA は、マルチドメインページを提供する場合に秒あたり平均わずか 44.9 要求であり、DHE-DSA は、単純なページを提供する場合に秒あたり44.8 要求に留まっています。明らかに、DHE のパフォーマンスは、使用する署名アルゴリズム（RSA または DSA）に関係なく、一貫して最低でした。

ECDSA 署名を使用した場合は、ECDHE-ECDSA のパフォーマンスが最速（単純なページを提供する場合は最高で秒あたり405 要求）であり、興味深いことに、全ページに渡って、Forward Secrecy を提供しない RSA-RSA よりも高速でさえあります。これは、RSA 署名アルゴリズムに対し、ECDSA署名アルゴリズムがサーバーのスループットを向上させることを示しており、Forward Secrecy の使用が実際に向かうところ敵なしであることさえも提示しています。

上記の観察を再確認するため、HEAD 要求を使用した場合の対応する測定値を比較します。HEAD要求は、TLSハンドシェーク後の完全なページ本体の伝送はスキップします（万一、ネットワーク帯域幅がサーバーのスループットのボトルネックであった場合に備えて）。当然のことながら、どちらの結果も一貫性のあるものであったことがわかりました。サーバーのスループットに関する結果を要約するため、以下の観察を引用します。

▪▪ DHE-RSA と DHE-DSA はどちらも、負荷下において非常に低いスループットパフォーマンスを示しました。DHE はスローであり、使用すべきでありません。

▪▪ ECDHE-RSA は RSA-RSA よりもはるかに悪いわけではありません。Forward Secrecy は基本的に向かうところ敵なしです。

▪▪ ECDHE-ECDSA は RSA-RSA よりも高速でした。Forward Secrecy は実際に（楕円曲線暗号を使用した）パフォーマンスを向上させます。

図 3 に、GET 要求で負荷がかかった状態でのサーバーのCPU 使用率を示します。DHE-DSA と ECHDE-RSA の場合に最も CPU 時間が使用されていることがわかります。つまり、これら 2 つの暗号スイートのボトルネックが CPU 計算によるものである可能性があることを示唆しています。DHE-DSA は複雑なページで最大 94% に達し、ECDHE-RSA は単純なページで最大 91% に達しています。

興味深いことに、ECDHE-ECDSA は最高のサーバースループットを提供した一方で、CPU 使用率は他のすべての暗号スイートよりもはるかに低いものでした。他方、ECDHE-ECDSA 用に処理されたコンテキストスイッチの回数はより増えていることが観察されました。

単純なページ複雑なページマルチドメインページ

0

100

200

300

400

GET HEAD GET HEAD GET HEAD要求タイプ

サーバースループット (要求/秒)

暗号スイートDHE-DSA

DHE-RSA

ECDHE-RSA

RSA-RSA

ECDHE-ECDSA

図2:合成トラフィック下でのさまざまな構成のサーバースループット

図3:GET要求下でのサーバーのCPU使用率

0

25

50

75

単純複雑マルチドメインページ

CPU 使用率 (%) 暗号スイート

DHE-DSA

DHE-RSA

ECDHE-RSA

RSA-RSA

ECDHE-ECDSA


15

4.2.2クライアント側の遅延このセクションでは、セクション 4.1.2 に記載した広告実験の結果を示します。合計予算の上限を 60ドルとして 2013 年5 月 14 日から 2013 年 6 月 5 日までの間、実験用の広告キャンペーンを実行した結果、合計 17,641 クライアントからログサーバーにデータが報告されました。これらのクライアントは必ずしも重複がないわけではなく、一部のクライアントは調査期間中に実験用広告を複数回訪れた可能性があることに注意してください。キャッシュされた接続を除外するため、実験結果のいずれかにゼロ値のサーバー接続時間、サーバー応答時間、または SSL セットアップ時間が含まれているクライアントからのデータは、破棄しました。また、ブラウザの実装バグにより異常な負の期間を報告したクライアントも、破棄しました。ログサーバーに報告を返した合計 17,641 クライアントのうち、結果が完全であった 10,043 クライアントのみが残りましたが、これらはすべて Chrome ブラウザでした。

図 4 に、それぞれの暗号スイートについて、SSL セットアップ時間、サーバー接続時間、ならびにサーバー応答時間の平均値と中央値の比較を示します。最初に、サーバーの応答時間を見ます。中央値は、DHE-RSA と ECDHE-RSA と RSA-RSA で 250 ミリ秒、ECDHE-ECDSA で 253 ミリ秒と、すべての暗号スイートに渡って極めて一貫性があることがわかります。このことは、今回の実験にとって素早い健全性検査として働きます。なぜなら、（SSL 接続が確立された後に）HTTPS 要求を送信してから、応答の第 1 バイトを受信するまでの時間は、鍵交換方式とは無関係でなければならないためです。

次に、SSL セットアップ時間を見ます。ECDHE-RSA（852ミリ秒）、DHE-RSA（878 ミリ秒）、ECDHE-ECDSA（958ミリ秒）と比べ RSA-RSA（833 ミリ秒）が最速であるこ

とを、中央値が示唆しています。RSA-RSA が DHE-RSAと ECDHE-RSA よりパフォーマンスが優れていることは予想されますが、非常に驚いたことに ECDHE-ECDSA は実際に RSA-RSA よりも低速でした。SSL セットアップ時間の平均値を見ると、ECDHE-ECDSA（2,939 ミリ秒）の値は、RSA-RSA（1,402 ミリ秒）と DHE-RSA（1472 ms）とECDHE-RSA（1,505 ミリ秒）の倍近い値でさえあることがわかります。サーバー接続時間（これは本質的に TCP ハンドシェークと SSL セットアップ時間の両方を含む）でも、まったく同じ傾向が観察されています。

ここで疑問は、なぜ ECDSA が RSA よりも低速となり得るのか、ということです。さらに調査した結果、Windows Vista以降のバージョンでは、ルート証明書が自動ルート更新メカニズムを通して配布されていることがわかりました [25]。つまり、ブラウザが新しいルート証明書に直面したとき、オペレーティングシステムは、そのルート証明書があるか Microsoft Update にクエリーし、見つかった場合はその特定の証明書をダウンロードします。結果として、クライアントは新しいルート証明書に直面したときに著しい遅延に直面している可能性があります。Windows CA ルート証明書ストアにおいて、我々のECDSA ルート証明書がデフォルトでは配布されなかったことを、手動で確認することができました※ 4。一方、我々の RSAルート証明書はデフォルトで配布されました。

TLS 調査について思い起こせば、ECDSA 署名を使用するホストは 2 台しか観察されませんでした（表 3）。従って、大多数のクライアントはまだいかなる ECDSA 証明書にも直面しておらず、この調査の証明書チェーンで使用された ECDSA ルート証明書もダウンロードされなかった、と仮定するのが理にかなっています。そのため、この広告実験ではクライアントに対してルート証明書をオンザフライでフェッチすることを要求して

SSLセットアップ時間サーバー接続時間サーバー応答時間

0

1000

2000

3000

平均平均平均中央中央中央

期間 (ミリ秒) 暗号スイート

DHE-RSA

ECDHE-RSA

RSA-RSA

ECDHE-ECDSA

図4:広告実験で測定されたクライアント側の遅延の平均値と中央値この調査でのECDHE-ECDSAに関する現実世界での測定値が理論上の予想と反する理由を、セクション4.2.2で考察する。

※ 4：フレッシュインストールされた Windows 8 と Windows Server 2012 では、ECDSA ルート証明書が配布されていなかったことを確認しました。


16

いた可能性があり、結果として ECDHE-ECDSA の SSL セットアップ時間が著しく長くなった可能性があります。さらに、調査結果として使用した 10,043 クライアントのうち、OS の分布は次のようになっていることを確認しました。Windows 7:8,627 クライアント、Windows 8:872 クライアント、Windows Vista:541 クライアント、Windows XP:3 クライアント。これは予想と一致しています。なぜなら、自動ルート更新メカニズムは Windows Vista 以降で有効になったため、Windows XP クライアントはそのほとんどが実験用ECDSA 証明書の検証に失敗したことが考えられるためです。今回のテストを完了した 3 台の Windows XP クライアントについては、手動でオプションのルート更新パッケージ [25] をインストールしていた可能性があります。

新しいルート証明書をフェッチするのは 1 回のみのコストであるため、初期訪問後は ECDHE-ECDSA が事実上、より高速に実行されるはずです。ただし、現在の調査データでは、ECDHE-ECDSA のクライアント側の遅延が他の暗号スイートよりも短くなるかどうか、結論づけることはできません。それでもなお、研究所内のみで測定を行うことで、そうしなければこの問題に気付くことさえなかったであろうことを考えると、この実験には価値があります。最後に、TLS のパフォーマンスを向上させるため、OS ベンダー（またはルート CA 証明書ストアソフトウェア）は、商用の ECDSA ルート証明書をデフォルトでプリインストールすることを推奨します。

5. 考察

Forward Secrecy の配備。今回の調査は、Forward Secrecy を配備することに対するパフォーマンスベースの議論は、もはや無効であることを示唆しています。Forward Secrecy を提供する ECDH ベースの鍵交換は、Forward Secrecy を提供しない基本の RSA-2048 鍵交換よりも高速となり得ます。このパフォーマンス向上の理由は、計算負荷の高い RSA-2048 復号が、より高速な secp256r1 楕円曲線演算で置き換えられることにあります。RSA-3072 やRSA-4096 のような、より長い RSA 鍵への推移が進むにつれ、ECDHE のパフォーマンスの強みがさらに顕著になるでしょう。今回の調査結果は、セキュリティとパフォーマンスの両面で、サイトが（極力）ECDHE に移行すべきであることを示唆しています。

楕円曲線における単一文化調査結果で少々驚いたことは、ECDHE をサポートしているサイトの 96.1% で、単一の曲線（NIST 曲線 secp256r1）を使用していることです。この曲線に対して特殊化された攻撃は現在のところないことを知っていますが、この特定の曲線に伴う弱みがいつの日か発見される可能性はあります。この曲線の人気を考えると、イン

ターネット上のほとんどのサイトに影響が及ぶことになります。secp256r1 は、予見できる将来に向けた使用に際しては、優れた曲線であり得ますが、この曲線に頼りすぎとなっている点は指摘しておく価値があります。

「RSA 認証」対「ECDSA 認証」。今回の調査が示しているのは、鍵交換には楕円曲線を使用するが、サーバー側の認証には RSA 署名を使用するのが、ECDHE を使用する場合の今日の一般的な方法であることです。理由は、サイトで主に保持しているのが RSA 公開鍵用の証明書であることです。セキュリティの観点から、これはセットアップとして好ましくありません。いずれのアルゴリズムに弱みが発見された場合も、サイトの TLS のセキュリティが打撃を被ります。先験的に、2 つのアルゴリズムの一方に弱みが発見される可能性は、単一のアルゴリズムに対する攻撃の可能性に比べ、はるかに大きくなります。結果として、ECDHE 鍵交換への移行を望むことになるため、サイトが ECDSA 公開鍵に対応した証明書に移行することには強力な論拠があります。

楕円曲線暗号（ECDSA-ECDHE など）のみに依拠することに比べ、RSA と ECDHE の両方（RSA-ECDHE と呼びます）を使用することのリスクを理解するため、次のような 3 つの可能性を考えます。

▪▪ RSA と NIST 曲線 secp256r1 のどちらも、十分なセキュリティを提供する。

▪▪ RSA は安全であるが、曲線 secp256r1 は安全でない。

▪▪ 曲線 secp256r1 は安全であるが、RSA は安全でない。

表 12 に、3 つのそれぞれのケースで、RSA-ECDHE とECDSA-ECDHE の結果として生じるセキュリティを示します。ECDSA-ECDHE は安全であるが、RSA-ECDHE は安全でないというシナリオがあるため、この表は、ECDSA-ECDHEが招くリスクは RSA-ECDHE よりも小さいことを示唆しています。逆は起こり得ません。ECDHE を使用することの要求を前提とすると、表 12 は、サーバー側認証用として楕円曲線公開鍵に移行することの論拠です。

表12:RSA-ECDHEとECDSA-ECDHEの比較

RSA-ECDHE ECDSA-ECDHERSAとsecp256r1がともに安全安全安全

secp256r1は安全だが RSAは安全でない安全でない安全

RSAは安全だが secp256r1は安全でない安全でない安全でない

適切に ECDSA 署名に移行するには、証明連鎖全体に渡って


17

CA がそれぞれの証明書に ECDSA 署名で署名することが必要になります。これにより、TLS 鍵交換のセキュリティが、単一（2 つではなく）の代数問題の解決困難性のみに依存することになります。楕円曲線上の離散対数問題（NIST 曲線secp256r1 上の）が、実際に現在我々が信じているとおりの解決困難性を持つかどうかは、時が経てばわかることです。

ECDSA 公開鍵に移行するということは、ECDHE 鍵交換の間にサーバーが ECDSA 署名を生成する必要があることを意味することに注意してください。ECDSA 署名アルゴリズムには、強力な乱数が必要です。乱数ジェネレータにおける偏りは、秘密署名鍵の無防備性につながります [26]。そのため、ECDSA 公開鍵に移行する場合は、サーバーに十分な乱数源を確保することが必要になります。代替案は（頻繁に使用されるものではない）、署名すべきメッセージに HMAC のようなPRF を適用することによって、ECDSA 乱数を導出することです。ここで、PRF 秘密鍵は署名鍵とともに保管されます。

DHE の誤設定。最後に、今回の調査は、DHE 鍵交換の配備に関する業界全体の設定の問題があることを示しています。

（2007 年の 6.14% と比べると）79% のウェブサイトがRSA-2048 に移行する一方で、DHE を使用するサイトの大多数が Diffie-Hellman プライムを 1024 ビットに設定しています。その結果、計算されたセッションキーを総当たり暗号解読攻撃によって回復する場合、2048 ビット RSA ではなく、1024 ビット Diffie-Hellman 問題を 1 つ解読すればいいことになります。2014 年までに CA/ ブラウザフォーラムは1024 ビットのセキュリティを不十分であると見なします。サイトでは可能な限り、RSA-2048 に匹敵するセキュリティを持つ（と推定される）楕円曲線を使用する ECDHE を支持し、DHE を破棄することを、我々は推奨します。

このような関連においては、1024-bit Diffie-Hellman パラメータが理にかなっているという異論もあり得ます。その理由は、Diffie-Hellman 値はエフェメラルであり、小数のセッションにしか使用されないことです。したがって、1024-bit Diffie-Hellman 問題への攻撃があっても、小数のセッションが無防備になるにすぎない、という理由です。この異論は、2つの要素により成り立ちが困難です。第 1 に、サイトは一層のセキュリティを求め、リソースと計算能力を費やして RSA-2048 に移行しました。しかし、1024-bit Diffie-Hellmanを使用していることで、どのセッションも 1024 ビットのセキュリティしか備えていないため、その投資からのメリットを受けていません。第 2 に、何らかの理由で攻撃者が特定の高価値セッションを標的にしようと決めた場合、そのセッションは 1024ビットのセキュリティで敵対するしかありません。言い換えれば、破られるセッションは 1 つだけであるにしても、その 1 つのセッ

ションは、攻撃者にとっては必要なすべてであるかもしれません。

6. 結論

ここ数年、TLS の Forward Secrecy に対するニーズが広く議論されるようになってきた一方で、サーバーは正しく設定され実装されていることが重要であり、そうでない場合、誤った安心感が生じます。このホワイトペーパーでは、まず最初に473,802 の TLS サイトにおける各種暗号化アルゴリズムの配備について調査し、DHE が有効になっているサイトの大多数が弱い DH パラメータを使用して設定されていることを報告しました。Forward Secrecy をサポートする各種暗号スイートを評価するため 2 つのパフォーマンス実験を行い、楕円曲線暗号を使用する Forward Secrecy が、従来の RSA アルゴリズムを前にして、実際に向かうところ敵なしであることを指摘しています。最後に、広告実験から測定される実世界でのクライアント側の遅延を分析し、Windows クライアント上で ECDSA 署名を使用する TLS 接続がルート証明書を更新する際に 1 回限りのペナルティに直面している可能性があることを観察しています。結論として、ウェブサイトが RSA から離れて Forward Secrecy を提供するとともに、極めて低速なDHE よりも ECDHE 鍵交換を配備することを、我々は強く推奨します。

謝辞この調査研究は、NSF と、シマンテック社の助成により支援されました。

7. 参考文献

[1] Alexaトップ1,000,000サイト http://www.alexa.com/topsites

[2] E. Abalea。バグ49559- ユーザー指定のDiffie-Hellmanパラメータを追加するためのパッチ（Bug 49559-Patch to add user-specified Diffie-Hellman parameters）。 https://issues.apache.org/bugzilla/show_bug.cgi?id=49559

[3] D. Akhawe、B. Amann、M. Vallentin、R. Sommer。証明書は信頼できるか。ウェブにおけるTLSエラー（Here's my cert, so trust me, maybe?:understanding TLS errors on the web）。 2013年第22回WWW国際会議セッションより。


18

[4] G. Apostolopoulos、V. Peris、D. Saha。TLSの真のコストとは（Transport layer security:How much does it really cost?）。 1999年IEEE INFOCOMセッションより。

[5] J. Ball。NSAのプリズム調査プログラム。どのように機能し、何ができるのか（NSA's Prism surveillance program:how it works and what it can do）。 http://www.theguardian.com/world/2013/jun/08/nsa-prism-server-collection-facebook-google

（2013年）。

[6] V. Bernat。SSL/TLSと完全なForward Secrecy （SSL/TLS&Perfect Forward Secrecy）。 http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html（2011年）。

[7] S. Blake-Wilson、N. Bolyard、V. Gupta、C. Hawk、B. Moeller。TLSのための楕円曲線暗号の暗号スイート（Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS））。RFC 4492（情報）May 2006年5月。RFC 5246により更新済み。

[8] CA/ブラウザフォーラム。公的に信頼される証明書の発行と管理の基準要件v.1.0（Baseline requirements for the issuance and management of publicly-trusted certificates, v.1.0）。 https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1.pdf（2011年）。

[9] C. Coarfa、P. Druschel、D. S. Wallach。TLSウェブサーバーのパフォーマンス分析（Performance analysis of TLS Web servers）。ACM Trans.Comput.Syst., 24（1）:39-69（2006年2月）。

[10] T. Dierks、E. Rescorla。TLSプロトコルバージョン1.2（The Transport Layer Security（TLS）Protocol Version 1.2）。RFC 5246（標準化への提唱）（2008年8月）。

[11] T. Duong、J. Rizzo。BEAST。 http://vnhacker.blogspot.com/2011/09/beast.html（2011年）。

[12] Z. Durumeric、J. Kasten、M. Bailey、J. A. Halderman。HTTPS証明書エコシステムの分析（Analysis of the HTTPS certificate ecosystem）。第13回ACM SIGCOMM Conference on Internet Measurementセッションより（2013年）。

[13] Electronic Frontier Foundation。EFF SSLの観測（The EFF SSL Observatory）。 https://www.eff.org/observatory

[14] A. O. Freier、P. Karlton、P. C. Kocher。SSLプロトコルバージョン3.0（The Secure Sockets Layer（SSL）Protocol Version 3.0）。 RFC 6101（歴史）、（2011年8月）。

[15] R. Graham。Torは依然DHE 1024。NSAによりクラック可能（Tor is still DHE 1024

（NSA crackable））。http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html （2013年）。

[16] V. Gupta、D. Stebila、S. Fung、S. C. Shantz、N. Gura、H. Eberle。楕円曲線暗号を使用した安全なウェブトランザクションの加速（Speeding up secure web transactions using elliptic curve cryptography）。第11回Annual Network and Distributed System Security Symposiumセッションより（2004年）。

[17] R. Holz、L. Braun、N. Kammenhuber、G. Carle。SSL俯瞰。能動測定と受動測定によるx.509 PKIの徹底分析（The SSL landscape:a thorough analysis of the x.509 PKI using active and passive measurements）。第11回ACM SIGCOMM Conference on Internet Measurementセッションより（2011年）。

[18] L.-S. Huang、E. Y. Chen、A. Barth、E. Rescorla、C. Jackson。趣味と実益についての独言

（Talking to yourself for fun and profit）。Web 2.0 Security and Privacyセッションより（2011年）。

[19] iSECPartners。SSLyze。 https://github.com/iSECPartners/sslyze

[20] C. Jackson、A. Barth、A. Bortz、W. Shao、D. Boneh。DNS Rebinding攻撃からのブラウザの保護（Protecting browsers from DNS rebinding attacks）。 ACM Conference on Computer and Communications Securityセッションより（2007年）。


19

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

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

[21] E. Käsper。OpenSSLにおける高速な楕円曲線暗号（Fast elliptic curve cryptography in OpenSSL）Financial Cryptography and Data Security国際会議セッションより（2011年）。

[22] A. Langley。Google HTTPSにおけるForward Secrecy（Forward secrecy for Google HTTPS）。https://www.imperialviolet.org/2011/11/22/forwardsecret.html（2011年）。

[23] H. K. Lee、T. Malkin、E. Nahum。SSL/TLSサーバーの暗号強度。現在と近年のプラクティス（Cryptographic strength of SSL/TLS servers:current and recent practices）。第7回ACM SIGCOMM Conference on Internet Measurementセッションより（2007年）。

[24] N. Mavrogiannopoulos。完全なForward Secrecyの適正価格（The price to pay for perfect-forward secrecy）。 http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html（2011年）。

[25] Microsoft Support。Windowsルート証明書プログラムメンバー。Windowsはどのようにルート証明書を更新するか（Windows root certificate program members-how windows updates root certificates）。 http://support.microsoft.com/kb/931125#MT5

[26] P. Nguyen and I. Shparlinski。浸透していないワンタイムパスワードによる楕円曲線デジタル署名アルゴリズムの非セキュリティ性（The insecurity of the elliptic curve digital signature algorithm with partially known nonces）。Design Codes Cryptography, 30（2）:201-217（2003年）。

[27] NIST。デジタル証明標準（Digital Signature Standard）。 Federal Information Processing Standards Publications, FIPS PUB 186-2（2000年）。

[28] Opera Software。TLS Prober。 https://github.com/operasoftware/tlsprober

[29] Qualys SSL Labs。信頼できるインターネット動向。SSL実装調査（Trustworthy Internet Movement-SSL Pulse）。 https://www.trustworthyinternet.org/ssl-pulse/

[30] E. Rescorla。セキュリティホール...誰が気にするであろうか（Security holes... who cares?）。第12回USENIX Security Symposiumセッションより

（2003年）。

[31] Apache Software Foundation。ab-Apache HTTPサーバーベンチマークツール（ab-Apache HTTP server benchmarking tool）。 https://httpd.apache.org/docs/2.4/programs/ab.html

[32] OpenSSLプロジェクト。OpenSSL:SSL/TLSのためのオープンソースツールキット（The open source toolkit for SSL/TLS）。http://www.openssl.org

[33] I. Ventura-Whiting。SSLScan- 高速SSLスキャナ（SSLScan-Fast SSL Scanner）。 http://sourceforge.net/projects/sslscan/

[34] Z. Wang。ナビゲーションのタイミング（Navigation timing）。 http://www.w3.org/TR/navigation-timing/

（2012年）。

[35] S. Yilek、E. Rescorla、H. Shacham、B. Enright、and S. Savage。秘密鍵はいつ公になるか。2008 年の Debian OpenSSL の脆弱性の結果（When private keys are public:results from the 2008 Debian OpenSSL vulnerability）。第9 回 ACM SIGCOMM Conference on Internet Measurement セッションより（2009 年）

tlsにおけるforward secrecyの 利用に関する実証的研究調査

Documents

tlsにおけるforward secrecyの利用に関する実証的研究調査