Partager via

使用 WireShark 追蹤透過 SSL 的 SharePoint 2010 與 Azure WCF 呼叫

  • Article

英文原文已於 2011 年 3 月 20 日星期日發佈

嘗試疑難排解遠端連線系統時其中一個有趣的挑戰是，理解它們彼此說了什麼。我在這個部落格上貼過的 CASI Kit (https://blogs.msdn.com/b/sharepoint_cht/archive/2010/12/17/azure-sharepoint-1.aspx) 是不錯的範例，它的主要用途在於提供線路將資料中心雲端連線在一起。疑難排解的其中一個難處是，流量會透過 SSL 周遊，所以相當難以疑難排解。我看了使用兩個 NetMon 3.4，其中現在有個 SSL 的 Expert 增益集 (可從 https://nmdecrypt.codeplex.com/ (可能為英文網頁) 取得) 以及 WireShark。我個人一向使用 NetMon，但是曾經在要讓 SSL 專家運作時發生了一些困難，因此決定試試看 WireShark。

WireShark 似乎已經支援了 SSL 好幾年，它只要求您提供與 SSL 憑證搭配使用的私密金鑰，該憑證會加密您的交談。我曾寫過 WCF 服務，因為它很容易就能取得。許多與 WireShark 有關的文件都建議您將 SSL 憑證的 PFX (匯出憑證並加入私密金鑰時所得到格式) 轉換為 PEM 格式。如果您讀過最新的 WireShark SSL Wiki (https://wiki.wireshark.org/SSL (可能為英文網頁))，不過該文其實不正確。實際上，Citrix 有篇不錯的文章說明有關如何設定 WireShark 使用 SSL (https://support.citrix.com/article/CTX116557 (可能為英文網頁))，但是文章中的指示太過隱密，而說明為 SSL 通訊協定設定中的「RSA 金鑰清單」屬性應使用的值 (如果您不確定那是什麼，請依照上述的 Citrix 支援文章執行)。所以，若要結合 Citrix 文章和 WireShark Wiki 上的資訊，這裡提供有關那些值的快速概要：

  • IP 位址 - 這是將所要解密的 SSL 加密內容傳送給您的伺服器 IP 位址
  • 連接埠 - 這是加密流量會經過的連接埠。若是 WCF 端點，可能永遠為 443。
  • 通訊協定 - 若是 WCF 端點，這應永遠為 HTTP
  • 金鑰檔案名稱 - 這是您儲存金鑰檔案的磁碟位置
  • 密碼 - 如果您使用 PFX 憑證，這是用來解開 PFX 檔案的密碼的第五個參數。Citrix 文章沒有提到這點，但 WireShark Wiki 有。

所以，假設您的 Azure WCF 端點位於 10.20.30.40 位址，而您的 PFX 憑證位於 C:\certs\myssl.pfx，密碼是 "FooBar"。那麼，您要輸入 WireShark 的 RSA 金鑰清單屬性的值為：

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

或者，您現在可以為 Windows 下載 OpenSSL，並從 PFX 憑證建立 PEM 檔案。我剛好發現這個下載的位置在 https://code.google.com/p/openssl-for-windows/downloads/list (可能為英文網頁)，但是網站上似乎有很多下載位置。一旦您下載硬體適用的位元之後，您就可以使用 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 金鑰清單屬性會是：

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

在這裡要提醒您一件事，就是您可以用分號新增多個項目。舉例來說，如我在 CASI Kit 系列中所述，我從裝載在本機伺服陣列的 WCF 服務開始著手，而服務可能是在 Azure 開發虛擬環境中執行。接著，我將它發佈到 Windows Azure。但是我在進行疑難排解時，可以點擊本機服務或 Windows Azure 服務。採用我在使用萬用字元憑證的 CASI Kit 中所述的方法時其中一個不錯的副作用是，它可讓我的兩個本機執行個體都使用與 Windows Azure 執行個體相同的 SSL 憑證。因此，在 WireShark 中，我只要指定如下兩個項目，也能使用相同的憑證來解密流量 (假設我的本機 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 的基礎，我其實昨晚用過。:-) 現在另一個棘手的問題是將 SSL 解密。主要問題似乎出自於我曾經執行過的作業，因此您必須確定您會在使用 SSL 端點進行交涉期間擷取。不幸的是，我發現在我嘗試追蹤透過 CASI Kit 傳出瀏覽器的 WCF 呼叫時，IE 和 Windows 的所有各種快取行為變得很難以執行。在瀏覽器上試了大約 2 個小時以上，結果只有一個追蹤傳回我實際在 WireShark 中解密的 Azure 端點，我感到快要抓狂。於是，解答再次回到 WCF 測試用戶端。

我發現要讓它持續地運作的方法是：

  1. 啟動 WireShark 並開始擷取。
  2. 啟動 WCF 測試用戶端
  3. 在您的 WCF (無論是您的本機 WCF 或 Windows Azure WCF) 加入服務參考
  4. 從 WCF 測試用戶端叫用 WCF 上的一或多個方法。
  5. 返回 WireShark 並停止擷取。
  6. 尋找任何通訊協定為 TLSV1 的框架
  7. 以滑鼠右鍵按一下該框架，並從功能表選取 [遵循 SSL 資料流]

隨即出現對話方塊，顯示未加密的交談內容。如果交談是空白的，可能表示私密金鑰未正確載入，或者擷取未包含交涉的工作階段。如果成功，感覺真的很棒，因為您可以看到整個交談，否則只有寄件者或收件者的內容。下列是我在透過 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