Risques potentiels de télécharger publiquement une trace Wireshark avec des informations liées à TLS?
Disons que je devais télécharger une trace Wireshark sur un site Web qui était accessible au public. Disons que le journal de clés SSL, les informations de certificat, etc. étaient disponibles. Si quelqu'un avait le lien avec la trace, quels dangers y aurait-il?
De toute évidence, le contenu et les informations de la session de trace donnée sont visibles par tout le monde, qu'en est-il d'une session passée ou future qui s'est produite? Qu'en est-il des sessions qui ont eu lieu avec d'autres clients ou d'autres serveurs? Pourrais-je être en danger de quelque chose comme une attaque de relecture ou une attaque de l'homme au milieu?
Si la trace wireShark a été créée du point de vue d'une écoute clandestine passive, il n'y a rien dans la trace qui pourrait être utilisé pour falsifier les futures connexions SSL/TLS.
Gardez à l'esprit que de nombreuses entités sont en mesure de faire la même trace que vous, notamment les opérateurs de hotspot sans fil, les FAI, les opérateurs de dorsale, les centres de données, etc. S'il était possible de falsifier les futures connexions SSL/TLS à l'aide de la trace que vous avez faite, alors n'importe laquelle de ces entités pourrait faire la même chose. SSL/TLS a été spécialement conçu pour résister à ce type d'altération.
Même si vous exécutez la trace sur le client et enregistrez les informations de session dans SSLKEYLOGFILE, les informations de ce fichier ne seront pas utiles pour falsifier les futures connexions SSL/TLS, car ce fichier contient uniquement des clés éphémères et des clés de session utilisées uniquement pour le session lorsque la trace a été effectuée.
Si quelqu'un n'a accès qu'à une capture de paquets et à aucun autre élément clé, il pourra évidemment voir des données non cryptées telles que le nom du serveur (SNI) et le certificat de serveur dans TLS 1.2, mais pas les données cryptées. TLS est conçu pour empêcher des tiers de falsifier la session et pour empêcher les attaques de relecture.
Le fichier généré par la variable d'environnement SSLKEYLOGFILE stocke généralement les secrets par session et est écrit par un point de terminaison (client ou serveur). Son format est documenté à https://developer.mozilla.org/NSS_Key_Log_Format
Pour TLS 1.3 , les secrets enregistrés ne seront utilisables que pour cette session particulière. Ces secrets ne peuvent pas être utilisés pour décrypter une autre session. Cela inclut les sessions précédentes, les sessions futures et les sessions avec d'autres clients ou serveurs. La raison en est que les secrets sont dérivés de la transcription complète des messages de prise de contact. Tout changement dans la prise de contact (par exemple, un client aléatoire différent ou un nom de serveur différent) entraînera un secret différent.
Pour TLS 1.2 et versions antérieures, la situation est presque la même. Cependant, il y a deux exceptions qui cassent la sécurité des futures sessions.
- Si les parties conviennent d'utiliser l'échange de clés RSA , la session ne sera pas transmise secrète. Cela signifie que si la clé RSA privée du serveur correspondant au certificat est compromise, le détenteur de cette clé privée pourra déchiffrer toutes les sessions précédentes et futures sur la base de la même clé de serveur. Cela ne s'applique pas si les deux parties utilisent une suite de chiffrement secrète directe basée sur l'échange de clés Diffie-Hellman. Ces dernières sessions seront toujours sécurisées même en cas de fuite de la clé privée RSA.
- Dans TLS 1.2, le secret principal est lié à une session. La reprise de session est un mécanisme par lequel un client peut tenter de réutiliser la clé principale d'une session antérieure. Il le fait en envoyant un identifiant (ID de session ou ticket de session) au serveur. Si le serveur reconnaît cela, il sautera la négociation complète et terminera une négociation abrégée sans effectuer un nouvel échange de clé. La nouvelle connexion ne sera pas sécurisée car obligation de garder le secret principal privé a été violée.
Le deuxième problème est subtil, mais très important. Il a été résolu dans TLS 1.3 où chaque session comprend toujours un échange de clé complet, rendant ainsi le "secret de reprise" indépendant des secrets réels qui seront utilisés pour le cryptage de la poignée de main et des données d'application.
Un exemple illustrant le problème de reprise de session TLS 1.2:
- Vous démarrez une capture Wireshark et ouvrez Firefox avec le jeu de variables d'environnement SSLKEYLOGFILE.
- Vous visitez un site Web, par exemple votre e-mail ou une boutique en ligne.
- À un moment donné, vous êtes satisfait de la trace des paquets capturés et arrêtez la capture Wireshark. Vous en faites une copie avec le contenu du fichier SSLKEYLOGFILE.
- Vous décidez de fermer l'onglet du site Web, mais sans quitter Firefox. Cela mettra généralement fin à la connexion réseau.
- Regarder le site Web était ennuyeux et comme vous vous êtes inspiré, vous rouvrez le site Web. Cela crée une nouvelle connexion.
- Vous vous connectez au site Web, envoyez un e-mail ou achetez quelque chose.
- Enfin, vous partagez la capture et les clés d'origine.
Le problème ici est que l'étape 5 pourrait finir par utiliser la reprise de session TLS 1.2. Un attaquant passif (MitM) qui voit le trafic de votre réseau (par exemple, dans un réseau Wi-Fi public dans un café) pourra utiliser les secrets de l'étape 7 pour décrypter votre activité à l'étape 6. Il pourrait potentiellement apprendre votre mot de passe, et faites des choses terribles avec.
Morale de l'histoire: oui, il est sûr de partager la capture de paquets avec le SSLKEYLOGFILE, mais assurez-vous qu'il ne comprend que des clés pour les sessions qui ne vous intéressent pas. Si vous souhaitez créer une trace pour le partage, utilisez une machine virtuelle ou utilisez un profil de navigation distinct. Un exemple de ce dernier peut être trouvé dans la diapositive 8 de mes diapositives sur l'exécution du décryptage TLS avec Wireshark: https://lekensteyn.nl/files/wireshark-tls-debugging-sharkfest19eu.pdf
Si vous ne pouvez pas démarrer un nouveau profil de navigation, vous pouvez au moins essayer de vider votre cache. Cela devrait garantir que la prochaine nouvelle connexion utilise de nouvelles clés.
Bien que vous l'ayez mentionné dans votre question, je le répéterai une fois de plus pour être complet: la trace décryptée peut révéler des cookies, des URL, des images, le contenu de la page Web et tout autre détail que vous avez partagé pendant la session de capture. Même si vous arrêtez votre capture locale, quelqu'un d'autre pourrait écouter et capturer tout dans la connexion existante. Une fois que vous avez publié les secrets, ils peuvent tout décrypter dans cette connexion.