日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

SSLWatcher: SSL/TLS 通信を監視し警告するハイパバイザ
平井成海髙橋一志大山恵弘

電子商取引やオンラインバンキングなどにおいて，機密性や完全性の確保には一般的に SSL/TLS が使用されている．しかし近年，SSL/TLS の安全性を脅かすような脆弱性が発見されており，問題となっている．また，サーバにおける不適切な SSL/TLS の設定は安全性を低下させてしまう危険があるが，ユーザがサーバの SSL/TLS の設定が適切であるか確認することは難しいため，意識しないまま安全性の低下した SSL/TLS 通信を使用してしまうリスクがある．本研究では，ハイパバイザを使用することで SSL/TLS を使用した通信を監視し，安全性が低下するような通信を検知し警告するシステムである SSLWatcher を提案する．また，SSLWatcher の実装を行い，安全性が低下する可能性のある 2 種類の通信と著名なサイトに対して SSLWatcher を使用した検出実験を行った．SSLWatcherを導入することによって通信のオーバーヘッドが発生することが懸念されるため通信のスループットの測定を行い，オーバーヘッドが最大約 104%になることを確認した．

量である．また，SSLWatcher の実装を行い，安全性

1 はじめにが低下する可能性のある 2 種類の通信と著名なサイ

電子商取引やオンラインバンキングなどにおいて，トに対して SSLWatcher を使用した検出実験を行っ

機密性や完全性の確保には一般的に SSL/TLS が使用た．SSLWatcher を導入することによって通信のオーされている．しかし近年，SSL/TLS の安全性を脅かバーヘッドが発生することが懸念されるため通信のすような脆弱性 [1] [7] が発見されており，問題となっスループットの測定を行い，オーバーヘッドが最大約ている．また，サーバにおける不適切な SSL/TLS の104%になることを確認した．

設定は安全性を低下させてしまう危険があるが，ユー

本論文の構成は以下の通りである．2 章で目的とザがサーバの SSL/TLS の設定が適切であるか確認す

ユースケースについて述べる．3 章で SSL/TLS につることは難しいため，意識しないまま安全性の低下しいて述べる．4 章で SSLWatcher の設計について述た SSL/TLS 通信を使用してしまうリスクがある．

べる．5 章で SSLWatcher の実装について述べる．6

本 研 究 で は ，ハ イ パ バ イ ザ を 使 用 す る こ と で章で SSLWatcher を使用した実験について述べる．7

SSL/TLS を使用した通信を監視し，安全性が低下

章で関連研究について述べ，8 章で本論文のまとめとするような通信を検知し警告するシステムである

今後の課題について述べる．

SSLWatcher を提案する．本研究では，ハイパバイザとして BitVisor [11] を使用する．BitVisor は PC の2 目的とユースケース

セキュリティ向上を目的としたハイパバイザであり，SSLWatcher で対象とする通信は HTTPS 通信，つOS 上ではなくハードウェア上で直接動作するため軽

まり SSL/TLS によって暗号化された HTTP 通信とSSLWatcher: A Hypervisor for Monitoring and Warning about Insecure SSL/TLS Communication
Narumi Hirai, Kazushi Takahashi, Yoshihiro Oyama,
電 気 通 信 大 学, The University of ElectroCommunications.

する．電子商取引やオンラインバンキングなど，通信内容の盗聴や改ざんが行われると金銭的な被害などが起こる可能性のあるサイトにおいて弱い暗号や弱い鍵交換が行われた結果，SSL/TLS による暗号化通順において行われる [2]．

ゲストOS

1. クライアントが対応しているバージョンや機能，
SSLWatcher

ハイパバイザ従業員

暗号スイートなどを送信する (ClientHello)
導入

H/W

2. 送信された情報を元に，暗号化通信に使用する管理者

暗号スイートを決定し返答する (ServerHello)

3. サ ー バ 側 か ら ，サ ー バ 証 明 書 を 送 信 す る
図1

SSLWatcher のユースケース(Certificate)
4. 必 要 に 応 じ て ，サ ー バ 主 導 の 鍵 交 換 を 行 う

信の安全性が損なわれると危険である．SSLWatcher
ではそのようなサイトを主な対象として，暗号化通信の安全性が損なわれるような通信が行われたときに警告を行う．

SSL/TLS 通信において，暗号アルゴリズムとハッ(ServerKeyExchange)
5. ServerHello の終了を通知し，クライアントからの応答を待つ (ServerHelloDone)

6. ク ラ イ ア ン ト 主 導 の 鍵 交 換 を 行 う(ClientKeyExchange)

シュアルゴリズムの組み合わせ (これを暗号スイート

7. 暗号化通信を開始する (ChangeCipherSpec)という) などを決定するハンドシェイク通信は平文でChangeCipherSpec 以降は，ハンドシェイクで得ら行われており，パケットキャプチャによってその内容れた暗号スイートを使用して暗号化通信が行われる．

を知ることができる．つまり，どのような暗号スイートが使用されるかなどの情報はパケットキャプチャによって知ることができ，この情報によって警告を行うことが可能である．

SSLWatcher の ユ ー ス ケ ー ス を 図 1 に 示 す ．

3. 2 脆弱性
SSL/TLS のプロトコルやその実装において発見された脆弱性のうち，ここでは FREAK [7] と Log-jam [1] について述べる．

SSLWatcher が対象とするユーザは HTTPS 通信の3. 2. 1 FREAK

セキュリティを向上させたいと考えている企業の管理

FREAK は SSL/TLS の輸出グレードの一時 RSA者とその従業員である．管理者は従業員の使用する鍵交換の実装における脆弱性であり，攻撃には以下のPC に SSLWatcher を導入し，従業員はその PC を使条件を要する．

用する．SSLWatcher はゲスト OS とハードウェアの間に存在し通常はパススルー動作を行う．そのため，• 対象サーバと被害者の間で中間者攻撃が成立すること

従業員は通常通り PC を使用することが可能である．

• 対象サーバが輸出グレードの一時 RSA 鍵交換

また，ネットワーク通信が行われた際にはその内容をを使用する暗号スイートを受け付けるように設見て HTTPS 通信が行われているかを調べる．新た定されていることに HTTPS 通信を発見した際には，ハンドシェイク• 輸出グレードの一時 RSA 鍵交換で使用する一通信を監視し警告が必要かを調べ必要に応じて警告

時鍵を対象サーバが使い回しており，計算等にを行う．

よって解読することが可能なこと
攻撃は，以下のように行われる．

3 SSL/TLS
この章では，SSL/TLS におけるハンドシェイクの手順と脆弱性について述べる．

1. 攻撃者は，対象サーバへアクセスし輸出グレードの一時 RSA 鍵交換で使用する一時鍵を得る

2. 攻撃者は，得た一時鍵を素因数分解し秘密鍵を得る

3. 1 ハンドシェイク
標準的な SSL/TLS のハンドシェイクは，以下の手

3. 攻撃者は，対象サーバと被害者との通信に中間者攻撃を行い，輸出グレードの一時 RSA 鍵交換

を使用する暗号スイートを使わせる

4. 被害者は，サーバから送信された一時鍵を使い4 SSLWatcher の設計

一時 RSA 鍵交換を行ってしまう (本来であれば

4. 1 システム全体

被害者は輸出グレードの一時 RSA 鍵交換を使用

SSLWatcher のシステム図を図 2 に示す．

する暗号スイートを使用していない)

まず，ハイパバイザはネットワーク通信をキャプチャ

5. 攻撃者は，鍵交換を盗聴し予め解読した一時鍵の秘密鍵で復号し共通鍵を得る

し，ポート番号を見て SSL/TLS 通信であるか調べる．

SSL/TLS 通信でない場合は無視し，SSL/TLS 通信

FREAK は輸出グレードの暗号をサーバが受け入であった際には通信内容のチェックを行う．チェッ

れてしまうことと，実装の脆弱性を突いて本来受けクを行う通信が SSL/TLS セッションにおける最初の入れないはずである一時鍵を受け入れてしまうこと通信の場合は，セッションを SSL/TLS セッションスが脆弱性の原因である．よって，FREAK の検出はトレージに登録する．SSL/TLS セッションストレーサーバから送信された一時鍵のビット数を調べるこ

ジには各セッションにおける，クライアントが対応とで行える．

している暗号スイートや使用している暗号スイート

3. 2. 2 Logjamが記録される．また，暗号スイートデータベースにLogjam は前項で説明した FREAK と似ているが，は SSL/TLS で使用される暗号スイートの暗号アルゴ

こちらは輸出グレードの一時 Diﬃe-Hellman (DH) 鍵リズムなどの情報が予め格納されている．SSL/TLS

交換を使用しており，実装の脆弱性ではなく TLS 自セッションストレージに登録されているセッション身の脆弱性である．攻撃には以下の条件を要する．の通信を発見した際には，記録されている情報を元に• 対象サーバと被害者の間で中間者攻撃が成立す警告が必要かを調べ，警告が必要な際にはディスプレること• 対象サーバが輸出グレードの一時 DH 鍵交換を使用する暗号スイートを受け付けるように設定されていること• 輸出グレードの一時 DH 鍵交換で交換される共通鍵を計算等によって解読することが可能なことイ上に警告を表示する．警告が行われる基準は以下の通りである．

• クライアントが対応している一番強度の高い暗号スイートのレベル (後述) より，使用している暗号スイートのレベルの方が低い場合 (ただし，RC4 は例外として除外する)

攻撃は，以下のように行われる．

• 弱い鍵交換が行われた可能性がある場合

1. 攻撃者は，対象サーバと被害者との通信に中間RC4 を除外している理由は，使用可能な最も強度者攻撃を行い，輸出グレードの一時 DH 鍵交換の高い暗号が RC4 というサイトの割合が未だ高く，を使用する暗号スイートを使わせるRC4 を警告してしまうとユーザにとって利便性が悪

2. 攻撃者は，被害者とサーバとの通信を記録するいシステムになってしまう可能性があるためである．

3. 被害者は，輸出グレードの一時 DH 鍵交換を行ってしまう (本来であれば被害者は輸出グレー

4. 2 暗号スイートにおけるレベル

ドの一時 DH 鍵交換を使用する暗号スイートをそれぞれの暗号スイートにはレベルが存在し，暗号使用していない)

4. 攻撃者は，一時 DH 鍵交換で交換された共通鍵を解読し，記録した暗号化通信を解読する

Logjam は鍵のビット数の少ない輸出グレードの一時 DH 鍵交換を行ってしまうことが脆弱性の原因である．よって，Logjam の検出は DH 鍵交換時に鍵のビット数を調べることで行える．

スイートの暗号アルゴリズムの強度が高いほどレベルの数値が高くなる．レベルを比較することで，暗号アルゴリズム同士の強度を比較することが可能である．
レベル情報は SSL/TLS ライブラリに含まれている情報を基本に，一部を変更したものとする．

能である．この機能によって HTTPS 通信が行われゲストOSるポートである 443 でのみ再構成を行うようにしている．

暗号スイート
データベース

SSL/TLSセッション
ストレージ

5. 2 セッションストレージ
libnids の TCP セッションの構造体 (tcp_stream)

SSL/TLS通信か？

Yes

通信内容のチェック

警告の必要ありと判定

通信のキャプチャ

警告画面の出力には user というメンバがあり，任意のデータを TCP
セッ ショ ン とと も に 保持 す るこ と が 可能 で ある ．

SSL/TLS の TCP セッションの確立時にセッションの内容を一時的に保存するための領域を malloc() で確保し，ポインタを user に格納することでセッショハイパバイザ

H/Wンストレージを実装している．

5. 3 暗号スイートデータベース
暗号スイートデータベースの実装には，OpenSSL

図2

SSLWatcher のシステム図の ssl/s2_lib.c と ssl/s3_lib.c に含まれている暗号スイートの構造体配列を使用した．この構造体配列には，それぞれの暗号スイートの使用する暗号ア

5 SSLWatcher の実装

ルゴリズム，ハッシュアルゴリズム，OpenSSL によ

SSLWatcher の実装は，BitVisor を改造することでる暗号の強度の分類などが格納されている．

行う．

5. 4 暗号スイートにおけるレベル
5. 1 BitVisor における通信のキャプチャと TCPの再構成

暗号スイートにおけるレベルは，基本的に OpenSSLによって決定された暗号スイートに割り当てられてBitVisor は標準でハイパバイザレベルでの VPN 機いる強度の情報から決定される．レベルは 0 から 4能をサポートしている．SSLWatcher では BitVisor

まで存在し，3DES はレベル 3，3DES 以外は表 1 のの VPN 機能を使用して，通信のキャプチャを行って基準で決定される．3DES を例外扱いしている理由いる．

は，3DES の OpenSSL での強度は HIGH であり，同また，パケットは送信された順番通りキャプチャできるとは限らない．SSL/TLS 通信は TCP で行われ

じ HIGH に分類される AES などと比較して強度が低いと考えられるためである．

るため SSLWatcher が再構成を行うことで順番通りパケットを受け取ることができる．BitVisor には組

表1

暗号スイートのレベル

み込み向けの TCP/IP スタックである lwIP [3] が内OpenSSL における強度蔵されているが，lwIP は再構成を行う目的で作成さNULL0

れていないため使用することは困難と判断した．そのEXPORT

1

ため，再構成を行うために Linux の TCP/IP スタッ

LOW

2

クをエミュレートした再構成を行うライブラリであMEDIUM

3る，libnids [6] を BitVisor 上に移植して使用するこHIGH4ととした．libnids は選択的な再構成の機能によって特定の TCP セッションのみ再構成を行うことが可レベル

5. 5 パケットを受け取った際の動作

表2

実験環境

パケットを受け取った際の SSLWatcher による動作は，以下の通りとなる．

• libnids によって受け取ったパケットが処理され，SSLWatcher に通知される．新規 TCP セッションの場合はポート番号が 443 であったら再構成を行うように選択する• ClientHello を発見した際には，使用可能な最CPUIntel Core i3 4000Mゲスト OS

Debian GNU/Linux 8

メモリ

4GB

カーネルのバージョン

3.16.0-4-amd64

OpenSSL のバージョン

1.0.1k

BitVisor のバージョン

1.4

も強度の高い暗号スイートをセッションストレー
ジに保存する• ServerHello を発見した際には，保存された暗号スイートと使用されている暗号スイートのレベルを比較し使用されている暗号スイートの方がレベルが低く，かつ RC4 でなかった場合は警告を行う• ClientKeyExchange と ServerKeyExchange を発見した際には，交換されようとしている鍵のビット長が 1024bit 未満であった場合は警告を行う
図3

弱い暗号スイートを検出した際の警告画面

5. 6 警告の表示
警告の表示には，BitVisor に含まれている機能であ

6. 1 弱い暗号スイートの検出実験

る ADvisor [9] を使用する．ADvisor はビデオ RAM

SSLWatcher を動作させた環境上で，暗号アルゴリに画像を直接書き込むことで，OS に依存しない画像表

ズムとして DES を使用するサーバへアクセスした際示を可能にする．また BitVisor では，SSLWatcher がに警告が表示され，正常に動作していることが確認で含まれている VPN 機能はモジュールとしてビルドさきた．検出時の警告画面のスクリーンショットを図 3れるため ADvisor 機能を直接使用できない．そのたに示す．

め，ADvisor 側に警告用画像を表示するための機能を

BitVisor の間接的な機能呼び出しを可能にするメッ6. 2 弱い鍵交換の検出実験

セージ機能から使用可能にすることで，SSLWatcher

実験には，FREAK と Logjam のテスト用サイト側から使用可能にしている．

を使用した．テスト用サイトの FQDN はそれぞれtls12cve.freakattack.com，dh512.zmap.io であ6 実験

る．SSLWatcher を動作させた環境上で，これらのテ

まず，SSLWatcher が正常に動作しているかを確か

スト用サイトへアクセスした際に警告が表示され，正めるための実験を 2 つ行った．次に，著名なサイトで常に動作していることが確認できた．検出時の警告の検出実験と通信のオーバーヘッドの測定を行った．

画面のスクリーンショットを図 4 に示す．

実験は，表 2 の環境で行った．

6. 3 著名なサイトでの検出実験
著名なサイトにアクセスした際の警告の度合いを調べるために，Alexa ランキングの世界ランキング

RC4 36 警告 2SSLなし
128

OK 334

図4

弱い鍵交換を検出した際の警告画面
図5

Alexa ランキングによる検出結果 (世界)と日本ランキングのそれぞれトップ 500 ドメインを使用して検出実験を行った．各ドメインに対して，
警告 2

SSL/TLS によるアクセスを試みた際の SSLWatcher

RC4 78の動作を調べることで実験を行った．世界ランキン

SSLなし
145

グを使用したときの結果を図 5，日本ランキングを使用したときの結果を図 6 に示す．それぞれ,• 「SSL なし」は，SSL/TLS サーバを提供していなかった場合• 「OK」は，問題がなかった場合• 「RC4」は，使用された暗号アルゴリズムが RC4だった場合
OK 275• 「警告」は，問題が見つかって警告が必要だった場合である．

図6

Alexa ランキングによる検出結果 (日本)

2 つのグラフより，警告が行われたサイトはそれぞれ 500 サイト中 2 サイト (0.4%) であった．警告が行• SSLWatcher あり，非 SSL/TLS 通信 (iperf)

われた理由は，すべてのサーバにおいて暗号アルゴリ• SSLWatcher あり，HTTP 通信 (wget)

ズムに DES が使用されていたためであった．

• SSLWatcher あり，HTTPS 通信 (wget)
iperf はデフォルト設定による測定，wget は 1GiB

6. 4 通信のオーバーヘッドの測定のファイルをダウンロードすることで測定を行った．

iperf と wget を使用して通信のスループットを測測定を 10 回繰り返し，平均値を取ることで最終的定することで，通信のオーバーヘッドを測定した．クな値とした．iperf によるスループットの測定結果をライアントとサーバは同一 LAN 内に存在し，1Gbps

図 7，wget によるスループットの測定結果を図 8 にの Ethernet で接続されている環境において，以下の示す．

条件で測定を行うこととした．括弧内はその条件の2 つの図より，iperf を使用したときの通信のオー測定に使用したソフトウェアである．

バーヘッドは最大約 31%，wget を使用したときの通• BitVisor なし (iperf，wget)

信のオーバーヘッドは最大約 104%となることが確認• BitVisor あり (iperf，wget)

できた．通信を主に行うプログラムではこの程度の

7. 2 SSL/TLS の設定に関する調査
Lee らの論文 [4] や Levillain らの論文 [5] では，イ
BitVisorなし

936.0

ンターネット上に存在する SSL/TLS サーバの設定を調査し，セキュリティ的な質を調べている．本研究にBitVisorあり

882.8おいては，SSL/TLS サーバの設定を調査することでセキュリティ的な質を調べるという考えを使用している．

SSLWatcher
非SSL/TLS通信(Mbps)

712.8

02004006008001000

7. 3 SSL/TLS のセキュリティ基準の決定
Pukkawanna らの論文 [10] では，サーバ証明書の図7

情報と使用されている暗号スイートなどの情報を元スループットの測定結果 (iperf )にスコアを算出し Best から Worst の 5 段階に分類することを試みている．SSLWatcher では使用されてBitVisorなし

896.0

いる暗号スイートのみでスコアに似た役割を持つレベルを算出しており，サーバ証明書の情報は使用してBitVisorあり

516.2

SSLWatcher
HTTP通信ことに加え，ユーザにとって不便となるような高い

439.0

検出率ではないため問題にはならないと考えられる．

SSLWatcher
HTTPS通信(Mbps) 0

いない．しかし弱い暗号スイートを検出できている

また SSLWatcher はハイパバイザ上に実装されてい480.21002003004005006007008009001000

るため，警告対象の通信の検知や警告が容易であることが異なる．

図8

スループットの測定結果 (wget)

また，Mozilla によって SSL/TLS サーバの設定例が公開されている [8]．HTTPS 通信を対象としておオーバーヘッドが考えられるが，実際のユースケース

り，ブラウザの互換性レベル別に Modern から Oldで使用されるプログラムでは通信以外の処理も行わまでの 3 種類の設定例がある．本研究においては，暗れると考えられるため，加わるオーバーヘッドはこれ号スイートのレベルの決定や警告基準に存在する例よりも小さくなることが予想される．

外を決めるための情報源として使用している．

7 関連研究8 まとめと今後の課題

7. 1 IDS/IPS

本研究では，SSL/TLS による暗号化通信の安全性

Snort [12] をはじめとする IDS/IPS は，ネットワーが損なわれるような通信が行われたときに警告を行

ク上の通信を監視しルールとして登録されている通信い，ユーザを守るためのシステムである SSLWatcher(主に不正アクセスと思われる通信が登録される) をの提案と実装を行った．また，SSLWatcher を実サイ検知して通知等を行うシステムである．IDS/IPS はトへ適用し弱い暗号スイートや弱い鍵交換の検出が通常ネットワーク上ではゲートウェイとして配置さ行えることを確認した．

れ，複数の PC の通信を監視する．そのため，ルール今後の課題としては，暗号スイートにおけるレベルにマッチする通信を検知した際に個別の PC に対しの計算にハッシュアルゴリズムの強度を含ませるこて通知することが難しい．一方，SSLWatcher では通と，サーバ証明書などのハンドシェイク上の使用して知に ADvisor を使用してディスプレイ上に直接警告いない情報の考慮，また通信のオーバーヘッドのさらを表示しているため，通知が容易である．

なる低減などが考えられる．また，現状の実装では警告対象の通信の切断を行なっていないため，この点に関する考慮も将来的には行いたいと考えている．

参 考 文 献[ 1 ] Adrian, D., Bhargavan, K., Durumeric, Z.,Gaudry, P., Green, M., Halderman, J. A., Heninger,N., Springall, D., Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Béguelin, S., andZimmermann, P.: Imperfect Forward Secrecy: HowDiﬃe-Hellman Fails in Practice, Proceedings of the22nd ACM Conference on Computer and Communications Security (CCS ’15), (2015).
[ 2 ] Dierks, T. and Rescorla, E.: The Transport
Layer Security (TLS) Protocol Version 1.2, RFC
5246 (Proposed Standard), August 2008. Updatedby RFCs 5746, 5878, 6176, 7465, 7507, 7568.
[ 3 ] Dunkels, A.: Design and Implementation of thelwIP, 2001.
[ 4 ] Lee, H. K., Malkin, T., and Nahum, E.: Cryptographic Strength of SSL/TLS Servers: Current
and Recent Practices, Proceedings of the 7th ACM
SIGCOMM Conference on Internet Measurement,
IMC ’07, San Diego, California, USA, ACM, 2007,
pp. 83–92.
[ 5 ] Levillain, O., Ébalard, A., Morin, B., and Debar, H.: One Year of SSL Internet Measurement,
Proceedings of the 28th Annual Computer Secu-rity Applications Conference, ACSAC ’12, Orlando,Florida, USA, ACM, 2012, pp. 11–20.
[ 6 ] libnids: http://libnids.sourceforge.net/.
[ 7 ] miTLS Team: FREAK: Factoring RSA Export
Keys, https://www.smacktls.com/#freak.
[ 8 ] MozillaWiki: Security/Server Side TLS, https://wiki.mozilla.org/Security/Server_Side_TLS.
[ 9 ] Oyama, Y., Ogawa, N., Kawasaki, Y., and Yamamoto, K.: ADvisor: A Hypervisor for Displaying
Images on a Desktop, Proceedings of the 2014 Second International Symposium on Computing andNetworking (CANDAR), Dec 2014, pp. 412–418.
[10] Pukkawanna, S., Kadobayashi, Y., Blanc, G.,
Garcia-Alfaro, J., and Debar, H.: Classification ofSSL Servers based on their SSL Handshake for Automated Security Assessment, Proceedings of International Workshop on Building Analysis Datasets
and Gathering Experience Returns for Security(BADGERS 2014), (2014).
[11] Shinagawa, T., Eiraku, H., Tanimoto, K.,
Omote, K., Hasegawa, S., Horie, T., Hirano, M.,
Kourai, K., Oyama, Y., Kawai, E., Kono, K., Chiba,S., Shinjo, Y., and Kato, K.: BitVisor: A Thin
Hypervisor for Enforcing I/O Device Security, Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, VEE ’09, Washington, DC, USA, ACM,
2009, pp. 121–130.
[12] Snort: https://www.snort.org/.