Analyser le trafic SSL dans Wireshark
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
Nicolas PANHALEUX
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).
Richo
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?
Nicolas PANHALEUX
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
hisham zahidi
svp ou je peux trouver la variable d’environement
ssllogfile sur linux
Nicolas PANHALEUX
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
gfh
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) ?
sreytan
La variable contient le chemin complet (=absolu) vers le fichier contenant les clés.
sreytan
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
Julien
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 😀