Utilisation de WireShark pour suivre vos appels SharePoint 2010 vers Azure WCF sur SSL

  • Article

Date de publication initiale de l’article : dimanche 20 mars 2011

Lors d’une tentative de dépannage de systèmes connectés à distance, découvrir ce que les systèmes échangent comme informations constitue l’un des défis les plus intéressants à relever.  Le Kit CASI dont j’ai déjà parlé dans ce blog (https://blogs.msdn.com/b/sharepoint_fr/archive/2010/12/16/kit-de-ressources-casi-160-160-partie-160-1.aspx) est un bon exemple dont le principal rôle est de raccorder des nuages de centres de données. Dans ce cas de figure, le dépannage s’avère plutôt difficile dans la mesure où le trafic est transmis par le biais du protocole SSL. J’ai donc envisagé la possibilité de recourir à NetMon 3.4, qui possède désormais un complément Expert pour SSL disponible à l’adresse https://nmdecrypt.codeplex.com/, ainsi que WireShark. Personnellement, j’ai toujours utilisé NetMon, mais ayant eu du mal à faire fonctionner l’expert SSL, j’ai décidé de tenter ma chance avec WireShark.

Il semble que WireShark prenne en charge le protocole SSL depuis maintenant quelques années ; il faut simplement fournir la clé privée utilisée avec le certificat SSL qui chiffre votre conversation. Puisqu’il s’agit d’un service WCF que j’ai moi-même écrit, ceci ne pose aucune difficulté. Une grande partie de la documentation relative à WireShark vous demande de convertir le PFX de votre certificat SSL (le format que vous obtenez lorsque vous exportez votre certificat et incluez la clé privée) au format PEM. Mais si vous consultez le dernier wiki SSL de WireShark (https://wiki.wireshark.org/SSL), vous constaterez que ce n’est pas la peine. Citrix propose un très bon article sur la façon de configurer WireShark de façon à utiliser le protocole SSL (https://support.citrix.com/article/CTX116557), mais les instructions sont beaucoup trop obscures lorsqu’il s’agit d’identifier les valeurs à utiliser pour la propriété « Liste de clés RSA » dans les paramètres du protocole SSL (si vous avez des doutes, consultez l’article de support technique Citrix mentionné ci-dessus). Ayant combiné les informations de l’article Citrix et du wiki WireShark, je suis en mesure de dresser un petit récapitulatif de ces valeurs :

  • Adresse IP - il s’agit de l’adresse IP du serveur qui envoie le contenu SSL chiffré que vous souhaitez déchiffrer.
  • Port - il s’agit du port par lequel passe le trafic chiffré. Pour un point de terminaison WCF, ce sera sans doute toujours le port 443.
  • Protocole - pour un point de terminaison WCF, ce doit toujours être HTTP.
  • Nom du fichier de clé - il s’agit de l’emplacement sur le disque où se trouve le fichier de clé.
  • Mot de passe - si vous utilisez un certificat PFX, il s’agit d’un cinquième paramètre qui correspond au mot de passe permettant de déverrouiller le fichier PFX. Ce paramètre n’est pas traité dans l’article Citrix, mais dans le wiki WireShark.

Supposons par exemple que votre point de terminaison WCF Azure soit à l’adresse 10.20.30.40 et que vous ayez un certificat PFX à l’emplacement C:\certs\myssl.pfx avec le mot de passe « FooBar ».  Dans ce cas, la valeur que vous devriez affecter à la propriété de liste de clés RSA dans WireShark serait la suivante :

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

En guise d’alternative, vous pouvez télécharger OpenSSL pour Windows et créer un fichier PEM à partir d’un certificat PFX. J’ai trouvé ce téléchargement à l’adresse https://code.google.com/p/openssl-for-windows/downloads/list, mais il semble exister de nombreux autres emplacements de téléchargement sur le Web. Après avoir téléchargé tous les éléments adaptés à votre matériel, vous pouvez créer un fichier PEM à partir de votre certificat PFX avec la ligne de commande suivante dans le répertoire bin OpenSSL :

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

En supposant que vous ayez procédé ainsi et créé un fichier PEM à l’emplacement C:\certs\myssl.pem, votre propriété de liste de clés RSA dans WireShark serait la suivante :

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

Autre élément à noter ici : vous pouvez ajouter plusieurs entrées séparées par des points-virgules. Par exemple, comme décrit dans la série d’articles sur le Kit CASI, je commence avec un service WCF hébergé dans ma batterie locale, exécuté éventuellement dans le tissu de développement Azure. Ensuite, je le publie dans Windows Azure. Mais lorsque j’effectue des opérations de dépannage, il se peut que je souhaite affecter le service local ou le service Windows Azure.  L’un des effets secondaires positifs de l’approche décrite dans le Kit CASI, qui consiste à utiliser un certificat générique, est que cela me permet d’utiliser le même certificat SSL pour mon instance locale et pour l’instance Windows Azure. Ainsi, dans WireShark, je peux également utiliser le même certificat pour déchiffrer le trafic en spécifiant simplement deux entrées telles que celles-ci (en supposant que mon service WCF local s’exécute à l’adresse 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

Voilà, en gros, comment configurer WireShark. L’autre difficulté consiste à déchiffrer le trafic SSL. D’après mon expérience, le point essentiel consiste à s’assurer que l’on effectue une capture durant la négociation avec le point de terminaison SSL. Malheureusement, je me suis rendu compte avec tous les différents comportements de mise en cache d’Internet Explorer et de Windows que cette opération était très difficile à effectuer lorsque je tentais de suivre mes appels WCF provenant du navigateur par le biais du Kit CASI. Après avoir essayé pendant près de deux heures dans le navigateur, je ne suis parvenu à déchiffrer dans WireShark qu’une seule trace obtenue sur mon point de terminaison Azure. Inutile de vous préciser que je commençais à devenir fou ! Une nouvelle fois, le client test WCF est venu à ma rescousse. 

Voilà enfin les étapes à suivre pour obtenir des résultats corrects de manière régulière :

  1. Démarrer WireShark et commencer une capture
  2. Démarrer le client test WCF
  3. Ajouter une référence de service à votre WCF (qu’il s’agisse de votre WCF locale ou de votre WCF Windows Azure)
  4. Appeler une ou plusieurs méthodes sur votre WCF à partir du client test WCF
  5. Revenir à WireShark et arrêter la capture
  6. Rechercher une trame où le protocole indique TLSV1
  7. Cliquer dessus avec le bouton droit et sélectionner Follow SSL Stream dans le menu

Une boîte de dialogue devrait alors apparaître et afficher le contenu non chiffré de la conversation. Si la conversation est vide, cela signifie probablement que la clé privée n’a pas été chargée correctement ou que la capture n’incluait pas la session négociée. Si tout fonctionne, le résultat est assez satisfaisant car on peut afficher au choix toute la conversation, uniquement la partie expéditeur ou uniquement la partie destinataire. Voici un court extrait de ce que j’ai obtenu à partir d’une trace vers ma méthode WCF sur le protocole SSL vers 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" blah blah blah

Voilà, j’espère que tout le temps que j’ai moi-même consacré à parvenir à cette solution vous permettra de basculer en mode dépannage un peu plus rapidement.

Ce billet de blog a été traduit de l’anglais. L’article d’origine se trouve à l’adresse Using WireShark to Trace Your SharePoint 2010 to Azure WCF Calls over SSL