Использование WireShark для трассировки вызовов SharePoint 2010 к Azure WCF по протоколу SSL

Исходная статья опубликована в воскресенье 20 марта 2011 г.

Одна из интересных проблем, возникающих при попытке устранения неполадок подключенных удаленным образом систем, состоит в выяснении того, что эти системы сообщают друг другу.  Набор CASI, о которым я как-то писал в этом блоге (https://blogs.msdn.com/b/sharepoint_ru/archive/2010/12/14/azure-sharepoint-1.aspx) — это хороший пример, главная цель которого — соединить центры обработки данных в облаке.  В этом случае одна из трудностей устранения неполадок состоит в том, что трафик передается по протоколу SSL, поэтому его довольно сложно обрабатывать.  Я рассматривал эту проблему как с помощью продукта NetMon 3.4, для которого есть надстройка Expert для работы с SSL и который можно загрузить по адресу https://nmdecrypt.codeplex.com/, так и с помощью и WireShark.  Лично я всегда использовал NetMon, но у меня были проблемы с SSL-модулем, поэтому я решил попробовать WireShark.

WireShark поддерживает SSL уже пару лет; необходимо просто указать закрытый ключ, используемый с сертификатом SSL, который шифрует беседу.  Так как службу WCF писал я, получить этот ключ несложно.  Документация по WireShark рекомендует преобразовать формат PFX сертификата SSL (формат, получаемый при экспорте сертификата и добавлении закрытого ключа) в формат PEM.  Если прочитать последнюю вики-статью по WireShark SSL (https://wiki.wireshark.org/SSL), то оказывается, что это не совсем так.  У Citrix есть хорошая статья по настройке WireShark для использования SSL (https://support.citrix.com/article/CTX116557), но инструкции всегда становятся непонятными, когда дело доходит до значений, которые нужно использовать для свойства "RSA keys list" в настройках протокола SSL (если вы не знаете, что это, ознакомьтесь со статьей Citrix, указанной выше).  Поэтому, совмещая эту статью Citrix и информацию из вики-статьи WireShark, можно получить краткий обзор этих значений:

  • IP-адрес — IP-адрес сервера, передающего данные, зашифрованные с помощью SSL, которые нужно расшифровать.
  • Порт — порт для получения зашифрованного трафика.  Для конечной точки WCF это почти всегда порт 443.
  • Протокол — для конечной точки WCF это всегда будет HTTP.
  • Имя файла ключа — распопложение файла ключа на диске.
  • Пароль — при использовании сертификата в формате PFX это пятый параметр, являющийся параметром для разблокировки PFX-файла.  Он не описывается в статье Citrix, но представлен в вики-статье WireShark.

Предположим, что конечная точка Azure WCF расположена по адресу 10.20.30.40, а сертификат PFX размещен по пути C:\certs\myssl.pfx с паролем "FooBar".  Тогда значение свойства "RSA keys list" в WireShark будет следующим:

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

Также можно загрузить OpenSSL для Windows и создать PEM-файл на основе сертификата PFX.  Я загрузил файл по адресу https://code.google.com/p/openssl-for-windows/downloads/list, но видимо в сети много других мест для загрузки.  После загрузки ПО, соответствующего вашему оборудованию, можно создать PEM-файл на основе сертификата PFX с помощью следующей команды в каталоге bin OpenSSL:

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

Допустим, вы сделали это и создали PEM-файл C:\certs\myssl.pem, тогда свойство "RSA keys list" в WireShark будет выглядеть следующим образом:

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

Еще один момент, которому стоит уделить внимание, — можно добавлять несколько записей, разделенных точкой с запятой.  Например, как я описал в статьях о наборе CASI, я начну со службы WCF, размещенной в локальной ферме, которая может работать в структуре разработки Azure.  Затем я опубликую ее в Windows Azure.  Но сейчас я занимаюсь устранением неполадок и хочу проверить локальную службу или службу Windows Azure.  Один из приятных побочных эффектов данного подхода, описанного в статье про CASI, — использование сертификата с подстановочными знаками, который позволяет применять один сертификат SSL как для локальных экземпляров, так и для экземпляра Windows Azure.  Поэтому в WireShark я также могу использовать один сертификат для расшифровки трафика, просто указав две записи следующим образомI (предоположим, что локальная служба 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.  К сожалению, из-за различного функционирования кэширования IE и Windows я обнаружил, что это довольно трудно при попытке выполнить трассировку вызовов WCF, поступающих от браузера через CASI.  Через 2 с лишним часа попыток я закончил всего одну трассировку конечной точки Azure, которую мне удалось расшифровать в WireShark, поэтому я постепенно сходил с ума.  На помощь опять же пришел тестовый клиент WCF. 

Вот, как нужно заставить все работать.

  1. Запустите WireShark и начните запись данных.
  2. Запустите тестовый клиент WCF.
  3. Добавьте ссылку на службу в WCF (локальную WCF или WCF в Windows Azure).
  4. Вызовите один или несколько методов WCF в тестовом клиенте WCF.
  5. Вернитесь в WireShark и остановите запись.
  6. Найдите любой кадр, соответствующий протоколу TLSV1.
  7. Щелкните его правой кнопкой и выберите Следовать за потоком SSL (Follow SSL Stream) в меню.

Откроется диалоговое окно с расшифрованнвм содержимом.  Если содержимое пустое, скорее всего закрытый ключ был загружен неправильно или записанные данные не содержат нужного сеанса согласования.  Если все работает, это здорово, потому что можно увидеть весь сеанс передачи данных или только данные от отправителя или получателя.  Вот небольшой пример полученных данных при трассировке вызовов WCF по протоколу SSL к Windows Azure:

  • 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" ...

Вот и все. У меня ушло довольно много времени, чтобы заставить все работать. Надеюсь, это поможет вам перейти в режим устранения неполадок быстрее, чем это получилось у меня.

Это локализованная запись блога. Исходная статья доступна по адресу Using WireShark to Trace Your SharePoint 2010 to Azure WCF Calls over SSL