トラブルシューティング:SSL プロトコルと暗号スイート

プロトコルと暗号アルゴリズム

TLS と SSL には異なるプロトコル バージョンがいくつか存在し、さまざまな暗号スイートが使用されています。クライアントとサーバが接続を行う場合は常に、その接続にどのプロトコル、どの暗号アルゴリズムを使用するのかが双方のエンドポイント間で合意されます。そのため、どのクライアント/サーバも、利用可能なプロトコルと暗号アルゴリズムの一定の組み合わせをサポートするように設定されています。クライアントとサーバの両方で利用できるプロトコル/暗号アルゴリズムの組み合わせが存在しない場合は、SSL のハンドシェイク エラーが発生し、接続は確立されません。ハンドシェイク エラーが発生した場合、AirWatch ではアプリケーション ログに標準的な SSL/TLS エラーが記録されます。

一般的には、新しい暗号アルゴリズムの方が古い暗号アルゴリズムよりも、暗号鍵の長さが長いものの方が短いものよりも、よりセキュアです。また、長い期間おいては、セキュリティ ホールが見つかったプロトコルや暗号アルゴリズムはすたれていき、新たに開発されたセキュリティ標準が採用されていく、ということが起こります。このような理由から、サーバやソフトウェアの多様なネットワーク コンポーネントに対して更新が加えられるため、互換性の問題が生じることもありえます。こうした互換性の問題は、個別に解決する必要があります。以下のセクションでは、このような問題がいつ発生しているのかを突き止め、それを解決するための手順について説明します。

Wireshark によるハンドシェイク エラーの特定

SSL/TLS のハンドシェイク エラーを特定するには、問題が発生している時点のネットワーク パケットを追跡するのが最も有効です。この作業を行うには、オープンソースのアプリケーション「Wireshark」(ここから入手可能) が役立ちます。サーバで Wireshark を実行すると、そのサーバが送受信するすべてのトラフィックが記録されます。したがって、クライアント サーバ (AirWatch サーバとの接続を調査する場合は MAG や SEG など) で Wireshark を実行することで、サーバ間でやり取りされる実際のデータを検証し、発生しているエラーを特定することができます。Wireshark によるパケット追跡では、追跡を開始した時点から終了した時点までのすべてのトラフィックが記録されます。その後、フィルタを適用して、分析対象のトラフィックに絞り込むことができます。以下に、有益な情報を追跡するためのベスト プラクティスを示します。

  1. 実施する検証操作の準備をできるだけ進めておきます。たとえば、接続テストのボタンをクリックした結果を検証する場合は、追跡を開始してすぐに接続テストを実行できるよう、該当 Web ページに移動しておきます。特定サービスの起動直後に接続に失敗するケースを調べる場合は、追跡開始後すぐにサービスを起動できるように準備しておきます。
  2. 追跡を開始します。
  3. エラーが発生する操作を行います。
  4. 追跡を停止します。無関係なトラフィックが記録されるのを最小限に抑えるために、追跡の開始から終了までの時間はできるだけ短くするのが理想です。
  5. フィルタを適用し、追跡結果を分析します。

ここでは、ハンドシェイク エラーが発生しているかどうか、またクライアントがサポートしている暗号スイートは何かを特定します。記録したトラフィックを絞り込むには、「ip.dst == xxx.xxx.xxx.xxx」のようなフィルタを適用します。このフィルタにより、クライアント サーバから IP アドレス「xxx.xxx.xxx.xxx」のサーバに向けて送信されたパケットだけが表示されます。さらに、「ssl」というフィルタを適用すると、SSL/TLS プロトコルを使用しているトラフィックだけが表示されます。この 2 つを合わせて「ip.dst == xxx.xxx.xxx.xxx && ssl」とすることで、これらのフィルタを一度に適用できます。特定の TCP ストリームに含まれるトラフィックだけに絞り込む場合は、まず関連するパケットを 1 つ見つけて、それを右クリックし、follow TCP stream を選択します。これにより、自動的にフィルタが適用されて、クライアント/サーバ間の、ある特定の要求に関連するトラフィックだけが表示されます。これは、個々のパケットに対する応答を特定するのに役立ちます。調査対象の通信を見つける手順としては、最初に前述のフィルタを適用して「Client Hello」パケットを見つけ、それを右クリックして、その TCP ストリームを確認する、という方法が有効です。

ハンドシェイク エラーの場合、下図のようなパケットが表示されます。この例は、該当の TCP ストリームに絞り込まれた状態です。先頭のパケットは「Client Hello」で、それに続き TLS ハンドシェイク エラーを示すサーバからの応答が表示されています。このようなパケットが見つかったら、ハンドシェイク エラーの根本原因を特定するために、クライアントとサーバのそれぞれでサポートされているプロトコルと暗号スイートを確認する必要があります。

image001.png

パケット追跡の別の例を下図に示します。この例では、ハンドシェイク エラーは発生していません。クライアントでサポートされている暗号アルゴリズムを特定する最善の方法は、「Client Hello」パケットを見つけて、その内容を確認することです。このパケットを選択し、Secure Sockets Layer > Handshake Protocol: Client Hello > Cipher Suites を展開してください。ここで表示される一覧には、クライアントがサポートする、利用可能なすべての暗号アルゴリズムが含まれています。また、暗号スイートの数行上には、ハンドシェイクの開始に使用された SSL/TLS のバージョンが表示されています。ハンドシェイク プロセスにおいて、双方のサーバは最終的に、これらの暗号アルゴリズムの中の 1 つを選択しようとします。双方が利用可能な暗号アルゴリズムがひとつでもあれば、ハンドシェイクは成功します。

image002.png

サーバで利用可能な暗号スイートの特定

ここまでで、クライアントで利用可能な暗号アルゴリズムは特定できました。続いて、サーバで利用可能な暗号アルゴリズムを確認します。ハンドシェイクが成功する場合、サーバは応答として「Server Hello」パケットを返します。このパケットは、使用する暗号アルゴリズムを特定した前述の方法と同じ方法で分析できます。しかし、ハンドシェイク エラーが発生する場合、Wireshark では、サーバが返す利用可能な暗号アルゴリズムを確認することができません。したがって、暗号アルゴリズムについての情報は、サーバに直接アクセスして入手します。サーバに物理的にアクセスできない場合は、状況に応じた各種 Web ツールを使用して入手することも可能です。特に、Qualys SSL Labs (ここからアクセス可能) のような Web サイトは、SSL/TLS の問題をトラブルシューティングするのに便利です。

使用するには、この Web サイトに移動し、接続先のサーバのパブリック URL を入力します。これにより、いくつかのテストが実行され、その結果が Web ページに表示されます。「Configuration」セクションには、利用可能な SSL/TLS プロトコルと暗号スイートの一覧が表示されます (下図)。このうち 1 つ以上のプロトコルと暗号スイートがクライアント サーバでもサポートされていることを確認してください。通常、この一覧は利用に適した順に表示されます。可能な限り最もセキュアなプロトコルを選択することが推奨されます。

image003.png

利用可能なプロトコルと暗号スイートの更新

上記の手順で確認した結果、クライアントとサーバの両方で共通してサポートされている暗号アルゴリズムが存在しなかった場合、少なくとも 1 つをクライアントまたはサーバで手動で有効にする必要があります。この作業は直接レジストリを編集して行うこともできますが、Nartac Software 社の「IIS Crypto」というツール (ここから入手可能) を使用するのがより簡単で便利です。

IIS Crypto を起動すると、そのサーバで使用できるプロトコルと暗号アルゴリズムのすべてを管理する画面が表示されます。必要な作業は、適切なオプションを選択し、Apply をクリックすることだけです。変更結果を反映するにはサーバを再起動する必要がありますが、これで利用可能なプロトコルと暗号アルゴリズムが更新されます。プロトコル/暗号アルゴリズムが正しく選択されていれば、上記の操作によりハンドシェイク エラーは解消されます。依然としてエラーが発生する場合は、上記の手順を繰り返し、調査内容や挙動に変化がないか確認してください。

image004.png

SSL/TLS プロトコルと暗号アルゴリズムについての注意点

近年のサーバ製品の多くは、SSL 3.0、TLS 1.0、TLS 1.1、および TLS 1.2 プロトコルを使用するトラフィックをサポートしています。ただし、SSL 3.0、TLS 1.0、 TLS 1.1 といった古いプロトコルを有効にすると、セキュリティ上の脆弱性が生じます。セキュリティ対策としては、サーバが使用するプロトコルと暗号スイートを最新のものに限定するのが一般的です。しかし、他のサーバや企業アプリと通信を行う場合、アプリの互換性を保証するために、古いプロトコルと暗号スイートを有効にしなければならない場合もあります。通常、クライアントとサーバのハンドシェイク プロセスでは、双方が利用できるプロトコルのうち最もセキュアなものを使用するようにネゴシエーションが行われます。

暗号スイートも同様で、数々の暗号スイートの中には、既知の脆弱性が含まれるものや、他の暗号スイートに比べ格段に強度が低いものがあります。使用する暗号スイートを決定する場合は、暗号方式自体と鍵交換メカニズムのそれぞれに違いがある点に留意してください。また、使用される暗号鍵の長さにも違いがあります (256 ビット、128 ビット、など)。暗号スイートの一例を次に示します。

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

この暗号スイートについては、次のことがわかります。

  • ECDHE RSA 鍵交換を使用している
  • AES 暗号方式を使用している
  • 256 ビット鍵長を使用している
  • CBC 暗号処理モードを使用している
  • SHA384 ハッシュ関数を使用している

暗号スイートが異なれば、使用される上記の機能の組み合わせも異なります。暗号スイートの安全性を見極めるには、これらのすべてを勘案する必要があります。だたし、一般的には AES 暗号方式が最も標準的であると考えられており、鍵長が長くなるほどセキュアになります (パフォーマンスとのトレードオフがあります)。AES 以外の暗号方式としては RC4 や 3DES が一般的ですが、安全性と効率の両立という点で AES が広く利用されています。

免責事項:これは英文の記事「Troubleshooting: SSL Protocols and Cipher Suites」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

Have more questions? Submit a request

0 Comments

Article is closed for comments.