1．はじめに

近年，インターネットにおける攻撃手法の進化に伴い，常時SSL/TLS化（完全HTTPS化）対応サイトがWebサービス企業を中心に増えている[1]．そこで，本稿ではSSL/TLSを安全に設定および管理するための手法や知見を過去の実施事例を通じて紹介する．

NTTグループでは，約10年の暗号危殆化対策推進の過程で，SSL/TLSの暗号設定確認の自動化ツールを開発している[2]．本ツールは，直近5年間で年2，3回，延べ1,000システム以上の検査実績があり，本稿で述べる知見の礎である．ただし，ツールは本稿の知見の実施例にすぎず，本稿で説明するSSL/TLS設定の外部検査手法はツールを限定せず利用可能なものである．本稿の想定読者としては，HTTP, TCP/IP等の通信の仕組みを理解しているが，SSL/TLSの通信の仕組みは専門でないシステム管理者を想定している．

本稿の構成を以下に述べる．第2章で知見の理解に必要な技術背景を述べる．第3章で課題と解決方針，解決方針の実施例である外部検査ツールの仕様を述べる．第4章でツールによる外部検査の効用と外部検査の実践で得られた知見を過去の実施事例を通じて述べる．第5章でまとめを行う．

2．技術背景

本章では，知見の理解に必要な技術背景として， SSL/TLSに関するプロトコル概要，システム運用，ネットワーク（以降NW）構成について述べる．

2.1　SSL/TLSプロトコルの概要と特徴

本節では，SSL/TLSプロトコルの概要を説明する．基本的な通信手順としては，最初にHandshakeプロトコルで通信の事前設定を行い，RecordプロトコルとApplication Dataプロトコルで暗号化通信を行う．通信の安全性を決めるのはおおむねHandshakeプロトコルで，通信の相手認証と暗号アルゴリズム・鍵・証明書の送受信を行い，暗号化通信のパラメタを決定する．クライアント／サーバが暗号化通信の設定を相互に交渉する過程は「ネゴシエーション」と呼ばれる．

SSL/TLSプロトコルの通信シーケンスを図1に示す．また，Handshakeプロトコルで使用されるメッセージ一覧を下記に示す．さらに，SSL/TLSプロトコルの通信内容の例を図6，7，8，10に示す（なお，説明の簡便のため，クライアント証明書は利用しない前提とする）．

• ClientHello

クライアントが対応可能なプロトコルバージョン，セッションID，暗号アルゴリズム一覧を送信する．

• ServerHello

サーバが，クライアントの提示した一覧から，対応可能として選択したプロトコルバージョン，セッションID，暗号アルゴリズムを送信する．

• Certificate

サーバ認証に必要なサーバ証明書を送信する．併せて，ルート認証局を辿るための中間証明書を送信する．

• ServerKeyExchange

DH（Diffie Hellman）方式で鍵交換を行う場合，鍵交換用のサーバ側公開情報をクライアントに送信する（RSA方式の場合，サーバ証明書内のRSA公開鍵を代わりに使用するため，本メッセージは不要である） ．

• ServerHelloDone

サーバからのメッセージ送信完了を通知する．

• ClientKeyExchange

DH方式で鍵交換を行う場合，鍵交換用のクライアント側公開情報をサーバに送信する．サーバ／クライアントは互いの公開情報を元にDH鍵生成を行う．

RSA方式の場合，クライアントが生成した乱数をサーバのRSA公開鍵で暗号化してサーバに送信する．サーバ／クライアントはこの値から鍵生成を行う．

• Finished

Handshake プロトコルの完了を通知する．一連のメッセージ全体にHandshakeプロトコルで決めた設定で暗号化を行い，メッセージ認証コードを付与する．

暗号化通信の代表的なプロトコルとしては，SSL/TLS，IPSec，SSH等があるが，SSL/TLSは設定確認の難易度が相対的に高いといえる．なぜなら，SSL/TLSは，不特定多数のクライアントとWebサーバの間で使用可能な複数のプロトコルバージョン／暗号アルゴリズムから動的にネゴシエーションして設定変更する手順を有し，この動的過程を考慮して設定確認を行う必要があるためである[3]．IPsecは，通信の両終端点を同一のシステム管理者が操作可能なことが多いため，設定の制御が比較的容易である[4]．SSHは，クライアント側でプロトコルバージョン／暗号アルゴリズムを決定してリクエストするため，システム管理者が各自利用するSSHクライアントに適切な設定を行えばよく，制御が比較的容易である[5]．

2.2　SSL/TLSのシステム運用

2.2.1　SSL/TLS設定の多層構成とシステム運用

SSL/TLSを安全に利用するためには，下記3点の設定および確認が必要である．

• （1）ライブラリバージョン
• （2）プロトコルバージョン
• （3）暗号アルゴリズムおよび鍵長の組合せ

まず，システムで利用するライブラリに脆弱性が存在する場合，ライブラリの設定確認やバージョン更新作業が必要となる．たとえば，Heartbleed脆弱性が発見された際，OpenSSLライブラリのバージョン確認および更新作業が業界全体で進められた[6]．また，ライブラリのバージョン更新では対処できない脆弱性が存在し，たとえば，SSLv3プロトコル仕様に重大な脆弱性が発見されて以降，各種サーバの設定変更でSSLv3をサポート対象外とすることが推奨されている[7]．さらに，暗号アルゴリズムの強度は計算機能力の向上とともに徐々に低下する問題があるため，より長期的な視点の対策が必要になり（暗号危殆化[8]），たとえば，暗号アルゴリズムRC4は以前より強度低下が指摘されているため，各種サーバの設定変更でRC4をサポート対象外とすることが推奨されている[9]．

安全で継続的なサービス提供のためには，ライブラリ／プロトコル／暗号アルゴリズムの3点セット（図2）の設定および確認作業に対応する必要がある．

また，これら設定および確認作業は不定期に必要になることが多く，人や組織にノウハウが定着しないことが多い．安全で継続的なサービス提供のためには，これら作業に組織として対応する必要がある．

2.2.2　後方互換性がもたらす煩雑な対策作業

前項の対策作業は，後方互換性（ex.古い端末へのサービス継続）の観点で，古い設定を残さざるを得ない場合に，システム管理者を悩ませる．たとえば，社内の情報セキュリティ主管がバージョン更新や設定変更を推奨しても，サービス主管が旧端末を使用するユーザへのサービス継続性の懸念から対策を許容しないことがあり，組織内の調整作業が必要となる．さらに，同じく後方互換性の観点で，OpenSSL等のライブラリ実装は古いプロトコルやアルゴリズムを残す場合があり[10]，これらの有効／無効化の影響調査と判断が必要となる．組織内の調整作業の低減とともに，対策作業自体の負荷を低減する設定確認手法が必要である．

2.3　高度化／複雑化したネットワーク構成

SSL/TLSを取り巻くネットワーク構成は，近年高度化／複雑化している．まず，Webサービス提供基盤（社外公開用NW）は，信頼性やスケーラビリティ確保，セキュリティ対策等の各要件を満たすために高度化／複雑化しており，リバースプロキシ/ロードバランサ/キャッシュ/ファイアウォール/IDS/IPS/WAF等のミドルボックスが介在することが一般的である[11]（図3）．また，社内業務用NWには，通信帯域制御，セキュリティ対策等の各要件を満たすために，フォワードプロキシ/キャッシュ/ファイアウォール/ Webフィルタリング等のミドルボックスが介在することが一般的である[11]（図3）．さらに近年は，クラウド上で上記機能を提供するサービスが存在し[12]，システム構成はさらに複雑化している．

これらネットワーク構成の高度化／複雑化により，システム管理者は各アプリケーションの通信を担っているサーバの把握が難しくなり，管理作業が煩雑になっている．SSL/TLS通信を終端するサーバにおいて適切な設定が行われる必要があるが，前述の構成ではミドルボックスがSSL/TLS通信を終端し，安全を確保すべき通信路が細分化するため，設定確認すべき個所と対策作業が増加する．たとえば，図3のネットワーク構成上のどこで通信を監視すれば，SSL/TLSの通信内容を適切に捕捉できるかの判断は非常に難しい．

3．課題と解決方針

3.1　課題

本節では，SSL/TLSの設定確認の課題を示す．

課題（α）設定確認すべき項目が膨大である

• SSL/TLSの暗号通信は，鍵交換／署名／共通鍵暗号／メッセージ認証の組合せ（以降CipherSuitesと呼ぶ）で行われ，有効／無効を確認すべきCipherSuitesはIANA[13]の規定で約330個に上る．また，プロトコルバージョン（SSLv2,v3, TLSv1.0,v1.1,v1.2）ごとに使用可能なCipherSuitesは異なり，有効／無効を確認すべき項目は掛け算で増加する．また，近年，PFS（Perfect Forward Secrecy）の観点で推奨されるDHE（Ephemeral Diffie-Hellman）およびECDHE（Elliptic Curve DHE）は[14]，ネゴシエーション過程で鍵長を決定するため，CipherSuitesからは鍵長が判定できない上，文献[15]発行時点（2015.5）でやや強度が低い鍵長が許容されていた経緯があり，鍵長の確認が必要である．さらに，Heartbleed[6]等のライブラリ実装への攻撃対策を含め，TLSプロトコル拡張機能（heartbeat, encrypt_then_mac etc.）がIANA[13]の規定で約27個存在し，プロトコルバージョンごとに有効／無効の確認が必要である．
• 不特定多数のユーザに提供するサービスでは，サービス継続性の観点で，古いブラウザ等特定のブラウザでアクセス時の挙動を個別に確認する必要がある．

課題（β）設定値の安全性評価に知識が求められる

• 各CipherSuitesが安全か否かを判定するには，暗号技術に関する専門知識が求められる．各CipherSuitesで利用する鍵交換／署名／共通鍵暗号／メッセージ認証アルゴリズムのうち，いずれか1つでも安全でない場合は，そのCipherSuitesは安全でないと判定するが，たとえば，SHA-1は（本稿執筆時点で）署名利用は安全でないがメッセージ認証は許容される等の例外が複数存在する．その他，同一のCipherSuitesでもプロトコルバージョン次第で安全性が異なるケース，PFSの観点で鍵交換アルゴリズムの鍵長が短くても許容されるケース，システムに求められるセキュリティ水準によりCipherSuitesの利用可否が異なるケース等，設定値の安全性評価には専門的な知識が求められる[15]．

課題（γ）設定値を特定することが難しい

• SSL/TLSの通信内容をパケットキャプチャした例を図6，7，8，10に示したが，設定確認すべき個所を目視で特定するには一定の時間と労力がかかる上，管理するサーバ規模次第では，全サーバを目視で設定確認することは確認ミスを招きやすい点でも望ましくない．
• SSL/TLS仕様では，クライアントは使用可能な暗号アルゴリズム候補を優先順に並べて送信し，サーバが使用する暗号アルゴリズムを決定するが，サーバ側の実装により，クライアントが提示する優先順位にしたがって決定する場合と，サーバが自身の優先順位にしたがって決定する場合があり，これら挙動の把握が必要である．
• 証明書に使用するアルゴリズムや鍵長の移行に際して，多くのサーバ製品で新旧の証明書の並存ができない問題があり，移行前後の設定確認が困難である．

3.2　解決方針

本節では，関連事例を参考に解決方針を述べる．

情報処理推進機構（IPA）のSSL/TLS暗号設定ガイドライン[15]は，電子政府推奨暗号リスト[16]に従い，SSL/TLSに推奨設定を適用するための方針を説明している．文中で，ネットワークやシステム構成によっては設定内容が実際の通信に反映されない可能性があるため，『外部からの監視／スキャンツールを用いたチェックと組み合わせる』必要性に言及している[15]．本稿は，上記言及に対して，外部検査の方法論を示し，各課題の解決を目指す．IPAのSSL/TLSアプライアンス製品の暗号設定方法等の調査報告書[11]は，より具体的な製品ごとの設定方法を説明するとともに，設定に対する挙動が製品ごとにさまざまである点に着目して，設定が正しく動作に反映されているかを実際に製品を動作させて検査している．本稿では，使用製品にかかわらず，実動作に沿った外部検査の方法論を示す．

3.3　ツール仕様

本節では，本稿知見の実現例であるNTTグループの暗号設定確認ツールの仕様を紹介する．本ツールは，SSL/TLSサーバとクライアントの挙動を模擬して，SSL/TLS通信を終端している個所に対して動的に外部検査を行う．TLSクライアント調査ツールおよびTLSサーバ調査ツールで構成される（図4）．

3.3.1　TLSクライアント調査ツール

調査対象のSSL/TLSクライアントに対して，擬似的なSSL/TLSサーバとして動作する．利用方法としては，クライアントが送信したClientHelloメッセージより暗号設定情報を収集し，安全性評価および利用可否の判定を行い，利用可否に応じて可視化・出力する．

3.3.2　TLSサーバ調査ツール

調査対象のSSL/TLSサーバに対して，擬似的なSSL/TLSクライアントとして動作する．利用方法としては，設定内容の異なるClientHelloメッセージを複数回送信し，応答されるServerHelloメッセージから暗号設定情報を収集し，安全性評価および利用可否の判定を行い，結果を一覧表で出力する（図5）．たとえば，図中 C1, C2等の欄にはCipherSuitesが約330個表示され，自動で安全性および利用可否が判定され，利用可否に応じて青／黄／赤の3色で可視化される[17]．

（CipherSuites例：TLS_DHE_RSA_WITH_AES_128_GCM_SHA256）

TLSサーバ調査ツールで対応可能な項目一覧を示す．

• （A）　暗号アルゴリズム検査
• （B）　暗号アルゴリズム選択優先権／優先順検査
• （C）　TLSプロトコル拡張機能検査
• （D）　SSL/TLSプロトコルバージョン−ダウングレード攻撃対策機能検査[18]
• （E）　証明書検査
• （F）　特定クライアント対向検査

項目（A）（E）（F）は，設定値の収集および安全性評価／利用可否判定を行い，利用可否に応じて3色に可視化を行う．項目（B）（C）（D）は，設定値の収集のみを行う．

4．外部検査の実践で得られた知見

4.1　ツールによる外部検査の効用

本節では，ツールによる外部検査の効用を述べる．4.1.1〜4.1.5項では，課題（α，β，γ）の解決方法に関して得られた知見を述べる．4.1.6項では，設定の多層構成に起因してツール検査の過程で発生した事例を知見として述べる．4.1.7項では，ツール検査の業務上の効率性について得られた知見を述べる．

4.1.1　ツール化による確認作業の容易化

本ツールは，SSL/TLSの通信内容を自動で解析する．手動で行う場合は，どのパケットに必要な情報が含まれるか特定するのに労力がかかり，人為的ミスが回避できない上，安全性評価や利用可否の判定には専門知識が必要である．これら課題に対して，ツール化により，人為的ミスを回避でき，かつ，SSL/TLSの知識なしに（A）〜（F）の設定確認が可能となることが分かった．

4.1.2　暗号アルゴリズム等検査対象の網羅性
（検査機能（A）（C）（D）の効用）

本ツールは，CipherSuites（図7，8の赤枠で例示）をプロトコルバージョンごとに特定個数ずつ指定して繰り返し実行し，使用可能なアルゴリズムを網羅的に確認する．また，TLSプロトコル拡張機能（図7，8の青枠で例示）をプロトコルバージョンごとに有効／無効を確認する．これら結果を図5の一覧表形式で出力することで，網羅性の確認が容易になると分かった．また，ClientHello，ServerHelloメッセージに加え， ServerKeyExchangeメッセージ（図6で例示）を確認することで，（EC）DHEの鍵長の判定が可能と分かった．

4.1.3　アルゴリズム選択優先権／優先順の挙動把握
（検査機能（B）の効用）

本ツールは，クライアントの暗号アルゴリズムの優先順位を入れ替えして接続要求し，入れ替え前後でServerHelloのCipherSuites選択結果が変わらなければサーバが選択権を有し，入れ替え前後で選択結果が変わればクライアントが選択権を有すると判定できる（図9）．また，サーバが選択権を有する場合は，ServerHelloで選択されたCipherSuitesを除外して再リクエストすることで，順々にサーバ側のCipherSuites優先順位を判定できる（図14）．これら判定ロジックにより，従来は動作時に判明していたサーバ側の選択優先権／優先順設定の内容を事前に検査可能と分かった．

4.1.4　証明書移行前後の外部検査
（検査機能（E）の効用）

本ツールは，Certificateメッセージ（図10に例示）を証明書フォーマット（X.509[19]）に従って解析し，署名／公開鍵アルゴリズムと鍵長を外部検査する機能を持つ．これにより，従来課題であった証明書移行前後の設定確認が可能と分かった．本設定値は手動で確認することも可能であるが，システム全体の更改等で多数サーバを一括で確認する必要がある場合には，4.1.1項で述べたようにツール化が有効である[15]．

4.1.5　特定ブラウザ⇔サーバ間の挙動把握
（検査機能（F）の効用）

本ツールは，図4のシステム構成により，特定ブラウザで接続時の挙動確認を自動化する．具体的には，ClientHello一式（図7で例示）をTLSクライアント調査ツールで収集し，TLSサーバ調査ツールでサーバに当該ClientHello一式を送信し，ServerHelloから選択された暗号設定（図8で例示）を確認可能とする．これらの機能により，特定ブラウザで接続時の挙動把握が可能となることが分かった．本挙動を手動で確認することも可能であるが，検査対象システムがサポートするブラウザが多数ある場合には，4.1.1項で述べたようにツール化が有効である．

4.1.6　ライブラリ構成に依存しない外部検査

ツール検査の過程で，利用ライブラリの認識誤りが原因で，設定と挙動に相違が生じる場合があった．Webブラウザは，OSベンダ製はOS組込みの機能を利用し，サードパーティ製はWebブラウザ組込みの機能を利用するため，選択される暗号設定は異なることがある．Webサーバは，RedHat等のOSバンドルのOpenSSL実装と，オープンソースのOpenSSL実装で，同じ設定に対して挙動が異なることがある（図11）．本稿で示す外部検査手法は，こうしたライブラリ構成に依存せず，暗号プロトコルおよび暗号アルゴリズムの設定確認に有効であることが分かった．

4.1.7　業務上の検査および情報共有の効率性

検査作業の効率性は，従来ツールの評価でサーバ1台あたり人手調査：25分に対してツール調査：3〜4分と試算されている[2]．さらに，組織として対策を進めるためには，対策推進部署への報告書作成に稼動がかかり，実際，フォーマット統一などの煩雑な作業のために検査の稼動の数倍はかかるという声がある．本稿のツール出力結果は，図5のように安全でない暗号アルゴリズムが使用される場合は警告色でハイライトされ，システム管理者が対策すべき個所が明確であり，関係部門に検査結果や実施証跡を共有することが容易になるため，部門間調整の効率化に役立つことが分かった．

4.2　実践で新たに分かった課題と工夫点

本節では，前節のツールによる外部検査を実践した結果，新たに分かった課題と工夫点を知見として述べる．4.2.1〜4.2.2項では，複雑なネットワーク構成に起因してツールの機能では解決できない事例が存在したため，ツールの利用方法により対応した知見をミドルボックスの種別ごとに述べる．4.2.3〜4.2.4項では，外部検査のシステム運用上の考慮事項を述べる．

4.2.1　ロードバランサ経由の検査

Webサーバの前段にロードバランサやCDN等キャッシュが配置される場合の知見を述べる．実際の運用において，ロードバランサ等がSSL/TLSの終端点であれば，ツール検査は当該終端点に対して行えばよい（図12）．ただし，サーバ証明書は，他サーバと共用する場合（ex.ワイルドカード証明書）と，各サーバ個別の証明書を利用する場合がある．後者の場合，証明書のツール検査結果は各Webサーバ個別の結果になる一方，暗号アルゴリズムのツール検査結果はロードバランサ等の共用の設定が反映される点に留意して，結果を確認する必要がある．

4.2.2　社内プロキシ経由の検査

社内NWからインターネットへのアクセス経路上に，ウィルスチェック等監視機能を有するプロキシが配置される場合の検査方法を説明する．監視機能は，暗号化通信を一度復号する必要があるため，クライアントとのSSL/TLSの終端点をアクセス先からプロキシに変更する必要がある（図13）．しかし，アクセス先のサーバ証明書をプロキシは当然流用できない．このため，実際の製品の動作例として，プロキシはダミーの認証局となり，ダミーのサーバ公開鍵を生成し，その公開鍵に対するダミーのサーバ証明書を生成し，クライアントとのSSL/TLS通信を終端する．この場合，社内から実施したツール検査結果は，サーバ証明書を含めてアクセス先の設定状況がまったく反映されないため，本稿ツールのプロキシ設定機能を利用するか，対象サーバに直接アクセス可能な別の経路を用意して検査を実施する必要がある．

4.2.3　検査対象サーバの負荷の低減

一般に，セキュリティ診断系ツールは，特に稼働中サービスに対しては，リクエスト回数や負荷などの影響が少ない方が望ましい．理由は2点あり，1点目は，診断系ツールのリクエストが検査対象サーバの監視ツールによりサーバへのスキャンやDoS攻撃として検出され，そのリクエストが切断される点，2点目は，監視ツールから大量の不要ログ出力が発生し，サービス運用上必要なログ解析に支障が出る点である．

本稿ツールでは，一度に送信するアルゴリズム数をエラーやタイムアウトが返るまで段階的に増加させることで，対象サーバが対応可能な最大数を判定し，図14のように一括判定するロジックを採用することで，リクエスト回数を低減した．また，リクエスト送信間隔を設定する機能により，検査に利用するネットワーク環境に応じて送信間隔を調整した．これら方法で，負荷を低減して検査を進められることが分かった．

4.2.4 システム管理者と検査者の業務分担

システム運用を委託している場合や，一部システムにクラウドサービスを利用している場合[12]，検査対象のシステム管理者とツール検査担当者の関係性を考慮して，検査を計画する必要がある．システム管理者が委託先の場合，委託先の運用するシステムに対する監査のような形になるため，ツール検査日時の事前周知，稼働中サービスに影響が生じた場合の対策および責任範囲，等の事前検討が必要である．ツール検査担当者が委託先の場合，実施工数の補填方法，検査および設定変更の対応範囲，検査結果の報告方法，等の事前検討が必要である．

5．おわりに

5.1　結論

本稿は，常時SSL/TLS化（完全HTTPS化）が進む背景を踏まえ，安全で継続的なWebサービス提供に必要なSSL/TLSの設定確認の方法や知見をシステム管理者に提供することを目指した．まず，設定確認のシステム運用上の課題を整理し，解決方針と，方針の具現化に有効なツールの仕様を説明した．次に，ツール検査の効用を説明し，ツール検査の実践で得られた知見を紹介した．本稿の内容の活用方法としては，たとえば，市中の検査ツールの動作の理解に役立てる，パケットキャプチャにより手動でサンプル検査を実施してみる，外注先に検査を依頼する際の参考情報としてもらうなどが考えられる．活用の際は，本稿の方法論と合わせて，文献[15][11]等の設定ガイドラインや個別の製品マニュアルを組み合わせて利用することが効果的である．

5.2　今後の動向

本稿で述べたSSL/TLS設定確認のプラクティスは，サービス提供を担う開発者／運用者にとって，必要不可欠であるが大変に労力のかかるものである．将来的には，こうした煩雑な設定確認が不要となることが望ましいと考えられる．業界動向として，仕様策定中のTLS1.3は使用可能な暗号アルゴリズムを安全性の高い少数に限定する方向で調整が進んでいる[20]．また，Appleが提案するATS（App Transport Secutiry）は同様に使用可能な暗号アルゴリズムを限定する方針である[21]．暗号アルゴリズムの設定で迷わない点は，開発者／運用者にとって望ましい方向性と考えられる一方，algorithm agilityがないことで，採用したアルゴリズムに仮に脆弱性が発見された場合に，設定変更で対処し難い点は，今後の評価が待たれる．

謝辞　本稿の執筆にあたり，これまで暗号危殆化対策を進められた，NTTテクノクロスの吉田勝彦様をはじめ，情報セキュリティ担当者皆様，特に，SSL/TLS設定確認ツール開発の担当者皆様の，継続的な取り組みに敬意を表し，ここに謝辞申し上げます．