Verwenden von WireShark zum Nachverfolgen von SharePoint 2010-Aufrufen an Azure WCF über SSL

Veröffentlichung des Originalartikels: 20.03.2011

Eine der interessanten Herausforderungen beim Versuch, Probleme bei remote verbundenen Systemen zu beheben, ist die Ermittlung, welche Informationen sie austauschen. Das CASI-Kit, zu dem ich in diesem Blog (https://blogs.msdn.com/b/sharepoint_de/archive/2010/12/14/toolkit-f-252-r-die-integration-von-forderungen-azure-und-sharepoint-teil-1.aspx) verschiedene Beiträge verfasst habe, eignet sich gut dazu, denn sein Hauptzweck ist es, Datencenterclouds miteinander zu verbinden. Eine der Schwierigkeiten bei der Problembehandlung ist, dass in diesem Fall der Datenverkehr über SSL übertragen wird, was die Problembehandlung erschweren kann. Ich habe sowohl NetMon 3.4, das nun über ein Experten-Add-In für SSL verfügt (Download unter https://nmdecrypt.codeplex.com/), als auch WireShark in Augenschein genommen. Ich persönlich habe zuvor stets NetMon eingesetzt, hatte aber Schwierigkeiten mit dem SSL-Expertenmodus, sodass ich beschloss, WireShark einmal auszuprobieren.

WireShark bietet wohl schon seit mehreren Jahren Unterstützung für SSL und erfordert lediglich die Angabe des mit dem SSL-Zertifikat verwendeten privaten Schlüssels, mit dem die Übertragung verschlüsselt wird. Da der WCF-Dienst einer von denen ist, die ich entwickelt habe, war dies kein Problem. In der Dokumentation zu WireShark wird häufig vorgeschlagen, das PFX-Format des SSL-Zertifikats (das sie erhalten, wenn Sie Ihr Zertifikat exportieren und den privaten Schlüssel einbeziehen) in das PEM-Format umzuwandeln. Doch wenn Sie denen neuesten Wiki-Artikel zu WireShark SSL (https://wiki.wireshark.org/SSL) lesen, stellt sich heraus, dass dies nicht unbedingt erforderlich ist. Citrix bietet einen lesenswerten Artikel zum Konfigurieren von WireShark für die Verwendung von SSL (https://support.citrix.com/article/CTX116557), doch die Anweisungen sind viel zu unklar, was die Werte angeht, die für die Eigenschaft "RSA keys list" in den SSL-Protokolleinstellungen anzugeben sind (wenn Sie nicht sicher sind, worum es geht, lesen Sie den genannten Artikel des Citrix-Supports). Die Informationen in diesem Citrix-Artikel und im WireShark-Wiki kombinierend folgt nun ein kurzer Überblick über diese Werte:

• IP address - Die IP-Adresse des Servers, der Ihnen mit SSL verschlüsselte Inhalte sendet, die Sie entschlüsseln möchten.
• Port - Der Port, über den der verschlüsselte Datenverkehr geleitet wird. Bei einem WCF-Endpunkt fast immer 443.
• Protocol - Bei einem WCF-Endpunkt immer HTTP.
• Key file name - Der Speicherort auf dem Datenträger mit der Schlüsseldatei.
• Password - Bei Verwenden eines PFX-Zertifikats ist dies der fünfte Parameter, d. h. ein Kennwort zum Entsperren der PFX-Datei, der nicht im Citrix-Artikel, aber im WireShark-Wiki behandelt wird.

Angenommen, Ihr Azure WCF-Endpunkt hat die Adresse 10.20.30.40 und ein PFX-Zertifikat im Verzeichnis C:\certs\myssl.pfx mit dem Kennwort "FooBar". Dann muss in WireShark in die Eigenschaft "RSA keys list" der folgende Wert eingegeben werden:

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

Alternativ können Sie OpenSSL für Windows herunterladen und anhand des PFX-Zertifikats eine PEM-Datei erstellen. Ich habe diesen Download unter https://code.google.com/p/openssl-for-windows/downloads/list gefunden, doch es gibt wohl im Internet noch viele andere Möglichkeiten zum Download. Nach dem Herunterladen der Bits für Ihre Hardware können Sie über den folgenden Befehl im OpenSSL-Verzeichnis bin anhand des PFX-Zertifikats eine PEM-Datei erstellen:

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

Wenn Sie so vorgegangen sind und eine PEM-Datei in C:\certs\myssl.pem erstellt haben, lautet die Eigenschaft "RSA keys list" in WireShark so:

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

Sie können hier auch mehrere Einträge hinzufügen, die durch Semikolons getrennt werden. Wie schon in der CASI-Kit-Reihe beschrieben, beginne ich z. B. mit einem WCF-Dienst, der in meiner lokalen Farm gehostet, in der Azure Development Fabric ausgeführt und dann in Windows Azure veröffentlicht wird. Doch wenn ich eine Problembehandlung durchführe, möchte ich je nachdem entweder den lokalen Dienst oder den Windows Azure-Dienst untersuchen. Einer der positiven Nebeneffekte des von mir im CASI-Kit beschriebenen Ansatzes zur Verwendung eines Platzhalterzertifikats ist, dass ich dasselbe SSL-Zertifikat für sowohl meine lokale Instanz als auch die Windows Azure-Instanz nutzen kann. Ich kann also in WireShark dasselbe Zertifikat für die Entschlüsselung von Datenverkehr verwenden, indem ich zwei Einträge wie die Folgenden angebe (vorausgesetzt, mein lokaler WCF-Dienst wird mit der IP-Adresse 192.168.20.100 ausgeführt):

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

Das sind die Grundlagen der Einrichtung von WireShark, die ich letzte Nacht wirklich hätte gebrauchen können. :-) Die andere echte Schwierigkeit ist nun die Entschlüsselung von SSL. Das Hauptproblem, das sich damit bei meiner Arbeit ergeben hat, ist, dass Sie dafür sorgen müssen, dass die Erfassung während der Verhandlung mit dem SSL-Endpunkt erfolgt. Leider habe ich bei all den verschiedenen Cacheverhalten von Internet Explorer und Windows festgestellt, dass die Erfassung überaus schwierig durchzuführen war, als ich versuchte, meine aus dem Browser stammenden WCF-Aufrufe mithilfe des CASI-Kits nachzuverfolgen. Nach etwas mehr als zweistündigen Versuchen im Browser konnte ich nur eine Ablaufverfolgung zurück zu meinem Azure-Endpunkt abrufen, die ich tatsächlich in WireShark entschlüsseln konnte, was mich fast wahnsinnig gemacht hat. Zu meiner Hilfe kam wieder einmal der WCF Test Client.

Die letztliche Schrittfolge, die ich ermittelt habe, ist wie folgt:

1. Erst WireShark und dann eine Erfassung starten
2. Den WCF Test Client starten
3. Ihrer WCF-Anwendung einen Dienstverweis hinzufügen (entweder Ihrer lokalen WCF- oder Ihrer Windows Azure WCF-Anwendung)
4. In Ihrer WCF-Anwendung über den WCF Test Client eine oder mehrere Methoden aufrufen
5. Die Erfassung in WireShark beenden
6. Den Frame suchen, bei dem das Protokoll TLSV1 lautet
7. Mit der rechten Maustaste darauf klicken und im Menü Follow SSL Stream auswählen

Ein Dialogfeld wird eingeblendet, in dem der unverschlüsselte Inhalt der Unterhaltung angezeigt werden sollte. Ist die Unterhaltung leer, bedeutet dies wahrscheinlich, dass entweder der private Schlüssel nicht ordnungsgemäß geladen wurde oder die Erfassung nicht die ausgehandelte Sitzung enthielt. Das Ergebnis ist sehr nützlich, da Sie entweder die gesamte Unterhaltung oder nur Daten vom Absender oder Empfänger anzeigen können. Es folgt ein kurzer Auszug, der in einer Ablaufverfolgung zu meiner WCF-Methode über SSL zu Windows Azure enthalten war:

• 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" und so weiter und so fort

Das war, was wir gewollt haben. Es hat eine Weile gedauert, bis alles wie gewünscht funktioniert hat. Ich hoffe, dass ich Ihre Bemühungen bei der Problembehandlung dadurch beschleunigen kann.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Using WireShark to Trace Your SharePoint 2010 to Azure WCF Calls over SSL.