web-dev-qa-db-fra.com

Décryptage de TLS dans Wireshark lors de l'utilisation de ciphersuites DHE_RSA

Comment puis-je décrypter les messages TLS quand une ciphersuite éphémère Diffie-Hellman est utilisée? Je suis en mesure d'exposer le secret prémaster et le secret maître du client SSL. En utilisant cela, comment décrypter les messages dans Wireshark?

encryptiontlsopensslwiresharkdiffie-hellman
48
Kalai

Quelques informations: Wireshark prend en charge le déchiffrement des sessions SSL lorsque le secret maître peut être calculé (qui peut être dérivé d'un secret pré-maître). Pour les suites de chiffrement utilisant l'échange de clés RSA, la clé RSA privée peut être utilisée pour déchiffrer le secret pré-maître chiffré.

Pour les suites de chiffrement éphémères Diffie-Hellman (DHE), la clé privée RSA est uniquement utilisée pour signer les paramètres DH (et pas pour le chiffrement). Ces paramètres sont utilisés dans un échange de clé DH, résultant en un secret partagé (en fait le secret pré-maître qui n'est bien sûr pas visible sur le fil).

Wireshark prend en charge diverses méthodes pour déchiffrer SSL:

  • En déchiffrant le secret pré-maître à l'aide d'une clé RSA privée. Fonctionne pour les échanges de clés RSA et sous réserve de la limitation ci-dessus.

  • Utilisation de n fichier SSL keylog qui mappe les identifiants pour maîtriser les secrets. Les identifiants disponibles sont:

    • Les 8 premiers octets (16 caractères hexadécimaux) d'un secret pré-maître chiffré (tel que transmis sur le câble dans le message d'établissement de liaison ClientKeyExchange). (RSA XXX YYY, puisque Wireshark 1.6. )
    • Les 32 octets (64 octets de caractères hexadécimaux) dans le champ aléatoire d'un message de négociation client Hello. (CLIENT_RANDOM XXX YYY, puisque Wireshark 1.8. )
      • Il existe également une variante qui mappe le client aléatoire à un secret pré-maître (plutôt que maître-secret). (PMS_CLIENT_RANDOM XXX ZZZ, puisque Wireshark 2. )
      • Une autre variante existe pour prendre en charge TLS 1.3 et mapper le client aléatoire sur les secrets respectifs. Au lieu de CLIENT_RANDOM, la clé est l'une des CLIENT_EARLY_TRAFFIC_SECRET, CLIENT_HANDSHAKE_TRAFFIC_SECRET, SERVER_HANDSHAKE_TRAFFIC_SECRET, CLIENT_TRAFFIC_SECRET_0 ou SERVER_TRAFFIC_SECRET_0. Depuis Wireshark 2.4 .
    • Le champ ID de session d'un message de négociation de Server Hello. (RSA Session-ID:XXX Master-Key:YYY, puisque Wireshark 1.6. )
    • Le ticket de session dans une extension client Hello TLS ou un message de négociation de ticket de session. (RSA Session-ID:XXX Master-Key:YYY, puisque Wireshark 1.11. )

Pour générer un tel fichier journal de clés SSL pour une session, définissez la variable d'environnement SSLKEYLOGFILE sur un fichier avant de démarrer l'application NSS. Exemples de commandes Shell pour Linux:

export SSLKEYLOGFILE=$PWD/premaster.txt
firefox

Sous Windows, vous devez définir une variable d'environnement global, soit via cmd (appelez setx SSLKEYlOGFILE "%HOMEPATH%\Desktop\premaster.txt" par exemple) ou via le panneau de configuration du système. Après cela, vous pouvez lancer Firefox via l'icône. Remarque : (Linux) les utilisateurs de Firefox avec NSS 3.24+ ne sont peut-être pas en mesure d'utiliser cette méthode car les développeurs de Firefox l'ont désactivée par défaut =.

Le fichier journal des clés SSL peut être configuré pour Wireshark à Modifier -> Préférences, Protocoles -> [~ # ~] ssl [~ # ~], champ (Pre) -Master-Secret log filename (ou passez le -o ssl.keylog_file:path/to/keys.log à wireshark ou tshark).

Après cela, vous pouvez décrypter les sessions SSL pour les captures précédentes et en direct. Si vous rencontrez une situation où vous ne pouvez toujours pas décrypter le trafic, vérifiez:

  • si le chemin du fichier journal de clé est correct (utilisez des chemins absolus au cas où le programme changerait le répertoire de travail).
  • si le fichier journal des clés contient réellement des éléments clés pour votre programme.
  • si Wireshark a été compilé avec GnuTLS (j'ai testé Wireshark 1.10.1 avec GnuTLS 3.2.4 et libgcrypt 1.5.3)
  • si d'autres sessions peuvent être déchiffrées. Par exemple, j'ai essayé https://lekensteyn.nl/ qui fonctionne, mais un site utilisant une suite de chiffrement Camellia a échoué.

Si vous ne parvenez toujours pas à décrypter tout le trafic, il est possible que Wireshark contienne un bogue (dans mon cas, il manquait le support de Camellia). Pour commencer le débogage, enregistrez votre capture et démarrez Wireshark avec la journalisation SSL activée:

wireshark -o ssl.debug_file:debug.txt savedcapture.pcapng

Une fois la capture chargée, vous pouvez refermer le programme. (Vous n'avez pas réellement besoin d'enregistrer la capture, mais cela facilite la reproduction du problème et évite davantage de bruit dans le vidage du journal.) Vous pouvez voir quelque chose de similaire à la ligne ci-dessous:

ssl_generate_keyring_material not enough data to generate key (0x33 required 0x37 or 0x57)

Ces nombres sont une combinaison des constantes définies dans epan/dissectors/packet-ssl-utils.h:

215-#define SSL_CLIENT_RANDOM       (1<<0)
216-#define SSL_SERVER_RANDOM       (1<<1)
217:#define SSL_CIPHER              (1<<2)
218-#define SSL_HAVE_SESSION_KEY    (1<<3)
219-#define SSL_VERSION             (1<<4)
220-#define SSL_MASTER_SECRET       (1<<5)
221-#define SSL_PRE_MASTER_SECRET   (1<<6)

Comme vous pouvez le voir, il me manque le SSL_MASTER_SECRET (0x20) ici. En regardant plus loin dans le fichier journal, je peux également trouver:

dissect_ssl3_hnd_srv_hello can't find cipher suite 0x88

Cette suite de chiffrement est en effet absente du cipher_suites structure définie dans epan/dissectors/packet-ssl-utils.c. Après avoir étudié RFC 5932 - Camellia Cipher Suites for TLS, j'ai trouvé les paramètres requis pour un CipherSuite. Le patch résultant devrait alors être soumis à Wireshark comme je l'ai fait ici: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9144 . La série 1.12 stable a une suite de chiffrement et un support TLS considérablement améliorés, vous ne devriez donc pas avoir à le corriger manuellement maintenant.

56
Lekensteyn

Si vous pouvez "dévoiler le secret prémaster", bien que l'échange de clés utilise éphémère Diffie-Hellman, alors vous avez un accès privilégié au client ou au serveur . C'est l'un des points de DHE: l'échange de clés réel utilise des paires de clés DH nouvellement générées, que ni le client ni le serveur ne stockent ailleurs que dans sa propre RAM. Avoir une copie de la clé du serveur permanent ne vous donnerait rien, en tant qu'attaquant passif avec Wireshark, car il n'est utilisé que pour les signatures. Cette clé pourrait être utilisée pour usurper l'identité du serveur et ainsi monter une attaque active Man-in-the-Middle .

Quoi que vous disiez, si vous avez accès au secret prémaster, vous devez également avoir un accès direct aux données claires, sans avoir à recourir à la capture de paquets grossiers; par conséquent, votre question est bizarre.

Quoi qu'il en soit, les enregistrements de données suivants peuvent être déchiffrés en suivant le standard (ou l'un des leprécédentversions , le cas échéant), ce qui est un exercice de programmation intéressant. Il est possible que le code source de ssldump soit réutilisé pour cette tâche.

9
Thomas Pornin