Analyser le trafic SSL dans Wireshark

octobre 08, 2013  |   Actualités,Blog   |     |   9 commentaires

Introduction

Dans bien des cas, il peut être interessant de visualiser les echanges entre un client et un serveur à l’aide d’outils open source comme Wireshark[3] qui permet de capturer le trafic réseau d’un ordinateur aussi bien sous Windows, Linux ou mac. Cependant, s’il est aisé d’analyser du trafic lorsqu’il transite “en clair”, cela est beaucoup plus compliqué dans le cas de flux chiffrés, tels que SSL.

Dans un cas concret, imaginons que nous souhaitons analyser les échanges entre notre navigateur et  notre webmail. Une fois les échanges capturés, nous pouvons observer quelque chose qui ressemble à ceci … :

Wireshark montre les echanges TLS (SSL v3.01) [4] entre les 2 machines, afin de procéder à la mise en place du canal sécurisé. Une fois ceci mis en oeuvre, nous ne voyons plus que des echanges de paquets TCP avec des charges utiles chiffrées. Pas très loquace …

Afin de parer à ce problème, les navigateurs tels que Mozilla Firefox ou Google Chrome offrent la possibilité d’exporter dans un fichier au format texte les informations issues de cet échange TLS. Information que Wireshark sait réutiliser. Voyons comment décrypter ces echanges …

Récuperer les informations TLS

Dans un premier temps, il faut définir une variable d’environnement sur votre système pour indiquer au navigateur où exporter ces données. Cette variable se nomme “SSLKEYLOGFILE”. Ecrivant cet article avec un système OSX, la manipulation est la suivante :

Ouvrir un terminal et entrer la commande suivante :

$ launchctl setenv SSLKEYLOGFILE ~/Desktop/tls.txt

Pour une machine fonctionnant avec Linux :

$ export SSLKEYLOGFILE=/protected/folder/my_session_keys.log

Enfin pour une machine fonctionnant avec Windows :

Ouvrir une invite de commande et taper :

C:\> set SSLKEYLOGFILE=c:\sslKeyLogFile.txt
C:\> "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"

Une fois cette opération réalisée, il faudra relancer le navigateur afin qu’il prenne en compte cette variable et retourner sur votre webmail après avoir lancer préalablement la capture sous Wireshark.

Dans mon cas, le fichier se remplit avec les informations suivantes :

# SSL/TLS secrets log file, generated by NSS
RSA 9452f369e7279b55 0301ca03ad5fa85a445bc78914c5608f8da43da4696661aa6ef45ab6af306037cdb319fa75f97ae21332a76ac329a83b
CLIENT_RANDOM 5235d4a52df4ef38b204d910c8f721c73312e624f229ddbf32bebeebf3e742e1 fb5485a739728d38cd75465ea45ebad840d67f29ff177535eaa0a4f9d403724ae65481b15ff990b4092d1a7c65223e28

Configurer Wireshark pour lire ces informations

Parmis les informations de ce fichier nous retrouvons :

  • Le nombre aléatoire RSA
  • Le PMS non chiffré
  • La valeur aléatoire servant au mecanisme Diffie Helmann
  • Le MS non chiffré

Wireshark effectue une recherche par bruteforce de la manière suivante et deux cas se présentent :

  • L’échange de clé a été effectué avec RSA
  • L’échange de clé a été effectué avec DH

Dans le premier cas, il comparera les 16 octets de RSA avec les 16 premiers octets de la PMS chiffrée du message “ClientKey Exchange”

-> Si le resultat est positif alors Wireshark utilisera le PMS et sera capable de générer le Master Secret puis la clé de session.

Dans le second cas, il comparera les 32 premiers octets avec le Random du “ClientHello”.

-> Si le resultat est positif alors Wireshark utilisera le MS et pourra générer la clé de session.

Afin que Wireshark utilise ces informations pour dechiffrer votre flux, il faut lui indiquer où se trouve ce fichier.

Lancer donc Wireshark et naviguer dans Edit => Preference.

Ensuite chercher le Protocole “SSL” dans le menu de gauche et indiquer le chemin vers notre fichier dans le champs “(Pre)-Master-Secret log filename” avant de valider par “Ok”.

Votre Wireshark devrait alors être capable de déchiffrer les flux utilisant cette clé.

On se rend alors compte que Wireshark detecte des flux HTTP dans les paquets TCP contenant des “Application Data” et que l’onglet “Decrypted SSL data” fait son apparition où nous pouvons voir les echanges effectués en HTTPs en clair !

Nous pouvons même faire un clic droit sur le flux et cliquer sur “Follow SSL Stream”. Nous nous retrouvons avec la transcription des echanges HTTPs dans son intégralité :

GET / HTTP/1.1
Host: monserveur.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
GET /index.html HTTP/1.1
Host: monserveur.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/css,*/*;q=0.1
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://monserveur.com/
Connection: keep-alive
POST /login.php HTTP/1.1
Host: monserveur.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://monserveur.com/
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 180
username=me%40monserver.com&password=monpwd&[...]

De cette manière, vous pourrez alors analyser tout le trafic chiffré en SSL que vous voudrez !

Bibliographie

[1] https://isc.sans.edu/forums/diary/Psst%20Your%20Browser%20Knows%20All%20Your%20Secrets%20/16415

[2] http://www.sans.org/reading-room/whitepapers/authentication/ssl-tls-whats-hood-34297

[3] http://www.wireshark.org/download.html

[4] http://en.wikipedia.org/wiki/Transport_Layer_Security

[5] http://www.ietf.org/rfc/rfc2246.txt

[6] http://www.sans.org/reading-room/whitepapers/authentication/ssl-tls-whats-hood-34297

9 Commentaires pour cet article

    Avatar
    Julien
    janvier 17th, 2016 on 2 h 09 min

    Humm du coup ça sert à quoi le SSL si on peut sniffer les paquets en claire ? tu fais un honeypot, tu te mets quelques part et tu attends que les gens se connecte à PayPal non ?

    J’ai dû mal comprendre 😀

      Avatar
      Nicolas PANHALEUX
      janvier 18th, 2016 on 12 h 44 min

      Bonjour,
      Merci pour votre commentaire.

      L’article explique comment analyser du trafic SSL sortant de son propre navigateur (à des fins de debug par exemple).

      Il ne permet pas de déchiffrer le trafic de son voisin puisque nous avons besoin des clés utilisées lors des négociations TLS (Celles que l’on récupère grâce à l’export de la variable SSLKEYLOGFILE).

        Avatar
        Richo
        avril 6th, 2017 on 21 h 15 min

        Merci pour la description et vos réponses aux questions. J’aimerais revenir en fait à la question de Julien.
        Si mon PC a été attaqué et que la personne a pu configurer une telle variable à mon insu, ne penses-tu pas qu’en capturant du trafic sur mon PC, il pourra après décoder en clair des infos confidentielles que j’ai dû peut-être échanger sur un site?

          Avatar
          Nicolas PANHALEUX
          avril 7th, 2017 on 7 h 36 min

          Bonjour Richo,

          Dès lors qu’un élément de la chaîne TLS est compromis, la sécurité du chiffrement l’est tout autant.

          Votre scénario implique deux choses :
          1 – Que votre PC est compromis par un utilisateur, soit ayant le droit de modifier vos variables d’environnement à long terme (Administrateur du poste) soit ponctuellement (vous prêter votre PC 5 minutes à un collègue).
          2 – Que cette même personne (ou un complice) soit capable de capturer le trafic de votre poste (Administrateur réseau)

          Effectivement, sous ces deux conditions, le trafic de votre PC sera déchiffrable par cette personne

    Avatar
    hisham zahidi
    avril 9th, 2016 on 1 h 02 min

    svp ou je peux trouver la variable d’environement
    ssllogfile sur linux

      Avatar
      Nicolas PANHALEUX
      avril 11th, 2016 on 18 h 04 min

      Bonjour,

      De base, la variable n’est pas positionnée sur le système. Il suffit alors de la déclarer à l’aide de la commande citée :
      # export SSLKEYLOGFILE=/protected/folder/my_session_keys.log

    Avatar
    gfh
    novembre 6th, 2016 on 17 h 57 min

    Bonjour,
    Lorsque l’on définit la variable pour permettre au navigateur d’exporter les données, où se situe le fichier ainsi exporté (my_session-key.log) ?

      Avatar
      sreytan
      novembre 30th, 2016 on 6 h 45 min

      La variable contient le chemin complet (=absolu) vers le fichier contenant les clés.

    Avatar
    sreytan
    novembre 30th, 2016 on 6 h 46 min

    Pour info, cette fonctionnalité a été désactivée par défaut en Firefox48 (modifiable par recompilation) mais semble avoir été réactivée en Firefox50+ source :https://bugzilla.mozilla.org/show_bug.cgi?id=1188657