WireShark を使用して SSL での SharePoint 2010 と Azure WCF の間の呼び出しを追跡する

  • Article

原文の記事の投稿日: 2011 年 3 月 20 日 (日曜日)

リモートで接続しているシステムのトラブルシューティングを実行するときの興味深い問題の 1 つとして、システム間での通信内容の把握があります。このブログの以前の投稿 (https://blogs.msdn.com/b/sharepoint_jp/archive/2010/12/16/azure-sharepoint-1.aspx) で説明した CASI キットは、データ センター クラウドへの接続を提供することが主な目的の場合に適した例です。トラブルシューティングにおける問題は、トラフィックが SSL で送信されるため、トラブルシューティング自体が難しくなる可能性があるということです。私が調査に使用したのは NetMon 3.4 と WireShark です。NetMon 3.4 は SSL 用のエキスパート アドインを備え、https://nmdecrypt.codeplex.com/ (英語) から入手できます.  個人的にはいつも NetMon を使用していますが、SSL エキスパートの機能に問題があったので、今回は WireShark を使用することにしました。

WireShark は、ここ数年、SSL をサポートしているようで、通信内容を暗号化する SSL 証明書で使用する秘密キーを指定する必要があります。WCF サービスは私自身が作成したので、取得するのは簡単です。WireShark に関する多数のドキュメントを読むと、SSL 証明書の PFX (証明書をエクスポートして秘密キーを取り込むときに取得する形式) を PEM 形式に変換するように提案されています。一方、最新の WireShark SSL wiki (https://wiki.wireshark.org/SSL (英語)) を読むと、そうした変換を行うのは正しくないことがわかります。Citrix では、SSL を使用するように WireShark を構成する方法について非常に有益な記事 (https://support.citrix.com/article/CTX116557 (英語)) を公開していますが、SSL プロトコルの設定の "RSA keys list" プロパティで使用する値の説明の意味がわかりません (私の説明の意味がわからなければ、この Citrix のサポート記事に従って操作してみてください)。この Citrix の記事と WireShark wiki の情報を総合すると、これらの値の意味を次のようにまとめることができます。

  • IP アドレス - これは、SSL によって暗号化されたコンテンツの送信元サーバーのアドレスです。このサーバーから送信される、SSL によって暗号化されたコンテンツを解読します。
  • ポート - これは、暗号化されたトラフィックを受信するポートです。WCF エンドポイントの場合、通常は 443 です。
  • プロトコル - WCF エンドポイントの場合、http を使用する必要があります。
  • キー ファイルの名前 - これはキー ファイルを格納しているディスク上の場所です。
  • パスワード - PFX 証明書を使用する場合、これは 5 番目のパラメーターで、PFX ファイルのロックを解除するパスワードを指定します。この値については Citrix の記事では説明されていませんが、WireShark wiki には説明があります。

そこで、たとえば、Azure WCF エンドポイントのアドレスが 10.20.30.40、PFX 証明書の場所が C:\certs\myssl.pfx、そのパスワードが "FooBar" であるとします。この場合、WireShark の RSA keys list プロパティに指定する値は次のようになります。

10.20.30.40,443,http,C:\certs\myssl.pfx,FooBar

また、OpenSSL for Windows をダウンロードして、PFX 証明書から PEM ファイルを作成することもできます。私は OpenSSL for Windows を偶然 https://code.google.com/p/openssl-for-windows/downloads/list (英語) からダウンロードしましたが、Web のさまざまな場所からダウンロードできるようです。ご利用のハードウェアに応じて適切なファイルをダウンロードしたら、OpenSSL bin ディレクトリで次のコマンドを実行して、PFX 証明書から PEM ファイルを作成できます。

openssl.exe pkcs12 -in <drive:\path\to\cert>.pfx -nodes -out <drive:\path\to\new\cert>.pem

上記の操作を実行して、C:\certs\myssl.pem に PEM ファイルを作成したとします。この場合、WireShark の RSA keys list プロパティは次のようになります。

10.20.30.40,443,http,C:\certs\myssl.pem

ここで、もう 1 つ注目すべき点があります。それは、セミコロンで区切って複数の項目を追加できるということです。たとえば、CASI キット シリーズで説明しているように、作業を開始するときに最初に使用した WCF サービスは、私自身のローカル ファームでホストする WCF サービスで、これはおそらく Azure 開発ファブリックで実行されると思われます。次に、私はこの WCF サービスを Windows Azure にプッシュします。ただし、私がトラブルシューティング担当者であれば、ローカル サービスまたは Windows Azure サービスまで達したいと思います。CASI キットで説明したワイルドカード証明書を使用するアプローチには、ローカル インスタンスと Windows Azure インスタンスの両方で同じ SSL 証明書を使用できるという利点もあります。したがって、WireShark では、次のように 2 つの項目を指定するだけで、トラフィックの解読に同じ証明書を使用することもできます (ローカルの WCF サービスが IP アドレス 192.168.20.100 で実行されていると仮定)。

10.20.30.40,443,http,C:\certs\myssl.pem;192.168.20.100,443,http,C:\certs\myssl.pem

以上が、WireShark の基本的な設定方法です。実は、昨夜遅くになってようやく WireShark を使用できました。もう 1 つおもしろいことがあります。それは、SSL の暗号化解除についてです。今回の作業の経緯から、これには大きな問題があると思われます。つまり、SSL エンドポイントとのネゴシエーション中にキャプチャを確実に実行する必要があるということです。IE と Windows の各種キャッシュ動作をすべて調べた結果、残念ながら、CASI キットを利用してブラウザーから受信する WCF 呼び出しを追跡しようとするときに、実際にキャプチャを実行するのは非常に難しいことがわかりました。ブラウザーで約 2 時間以上試してみましたが、WireShark で実際に暗号化解除できた Azure エンドポイントに 1 つさかのぼることができただけで、後は疲れただけでした。そこで、今度は、WCF テスト クライアントを使用することにしました。

この作業を一貫して実行する手順がようやくわかりました。

  1. WireShark を起動し、キャプチャを開始します。
  2. WCF テスト クライアントを起動します。
  3. WCF の参照を追加します (ローカルの WCF または Windows Azure WCF のどちらか)。
  4. WCF テスト クライアントから WCF に対して 1 つ以上のメソッドを呼び出します。
  5. WireShark に戻り、キャプチャを停止します。
  6. プロトコルが TLSV1 を示しているフレームを探します。
  7. そのフレームを右クリックし、メニューから [Follow SSL Stream] を選択します。

ダイアログがポップアップし、暗号化が解除された通信内容が表示される必要があります。通信内容が空の場合は、秘密キーが正しく読み込まれなかったか、ネゴシエートされたセッションがキャプチャされなかったことを示しています。適切に機能すれば、通信内容をすべて表示できます。また、送信者または受信者の情報のみを表示することもできます。次に、SSL での Windows Azure に対する WCF メソッドのトレースから取得した情報を簡単にまとめます。

  • POST /Customers.svc HTTP/1.1

  • Content-Type: application/soap+xml; charset=utf-8

  • Host: azurewcf.vbtoys.com

  • Content-Length: 10256

  • Expect: 100-continue

  • Accept-Encoding: gzip, deflate

  • Connection: Keep-Alive

  • HTTP/1.1 100 Continue

  • HTTP/1.1 200 OK

  • Content-Type: application/soap+xml; charset=utf-8

  • Server: Microsoft-IIS/7.0

  • X-Powered-By: ASP.NET

  • Date: Sat, 19 Mar 2011 18:18:34 GMT

  • Content-Length: 2533

  • <s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope" blah blah blah

これでおわかりでしょう。この結果を得るまでに時間がかかりました。この記事が皆様の迅速な問題解決に役立つことを願っています。

これはローカライズされたブログ投稿です。原文の記事は、「Using WireShark to Trace Your SharePoint 2010 to Azure WCF Calls over SSL」をご覧ください.

-D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; <![CDATA[X-2D;Powered-2D;By: ASP.NET ]]-->

-D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; <![CDATA[Date: Sat, 19 Mar 2011 18:18:34 GMT ]]-->

-D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; <![CDATA[Content-2D;Length: 2533 ]]-->

-D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; -D;-A; <![CDATA[]]-->