j'essaie de décrypter une trace réseau SSL V3 RC4 128 bits sur une
platform Windows.
J'ai réussi à décrypter la pre-master key et je génère maintenant les
clefs de sessions... qui ne décryptent pas.
Je pense avoir un problème avec le client et server random.
Question:
Faut-il transformer ces octets de big endian vers little endian?
1. Inverser les 32 octets tous ensembles?
2. Inverser les 4 premiers octets de timestamp séparément des 28
octets random restants?
3. Ne rien inverser.
J'aurais la même question avec les données encryptées:
Faut-il inverser les octets avant de décrypter? ( car quand je lis une
trame http en clair, je n'ai pas besoin d'inverser les octets).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
pornin
According to Big joke :
Je pense avoir un problème avec le client et server random. Question: Faut-il transformer ces octets de big endian vers little endian?
Non. Ce sont 32 octets complètement anonymes. Même les 4 premiers octets de "timestamp" sont à traiter comme les autres ; d'ailleurs, rien n'impose au juste un client de mettre un timestamp correct (en fait, le standard décrivant SSL/TLS impose au serveur de ne pas s'offusquer même s'il trouve n'importe quoi en lieu et place du timestamp).
La dérivation des clés (de chiffrement et de MAC) utilise la "PRF" (pseudo-random function) spécifique à SSL/TLS pour faire le boulot. Cette fonction va utiliser le random du serveur, celui du client, et le "master secret". Quelques points importants :
-- Il y a SSL 3.0 et TLS 1.0. TLS 1.0 est en fait SSL 3.1. TLS 1.0 est standard, et décrit par la RFC 2246. SSL 3.0 n'est pas standard ; on doit pouvoir trouver un draft sur le site web de Netscape (en cherchant bien à coups de google). SSL 3.0 et TLS 1.0 n'utilisent PAS la même PRF. La version utilisée pour un échange donné est celle utilisée par le serveur dans son "ServerHello".
-- Même si c'est pour faire du SSL 3.0 ou 3.1, certaines implémentations envoient un ClientHello en SSL 2.0 (mais spécifiant que le SSL 3.0 est supporté) ; la RFC 2246 indique comment est calculé le "client random" dans ce cas-là.
-- Pour calculer les clés, on utiliser les deux randoms et le "master secret". Le "master secret" est lui-même dérivé du "pre-master secret" (et des deux randoms) avec la PRF. Ce qui veut dire qu'entre le pre-master secret (le mot de 48 octets commençant par la version et chiffré en RSA, si le serveur utilise une clé RSA) et les clés de chiffrement, il y a _deux_ couches de PRF. On en oublie facilement une, surtout que le "master secret" fait lui aussi 48 octets de long.
-- Ne pas oublier qu'il y a deux clés de chiffrement, une dans chaque sens. De plus, il faut bien rester synchronisé avec les messages et ne pas en sauter. Le premier message chiffré dans chaque sens est un message "Finished", et pas les données directement.
En résumé : c'est compliqué. Il semblerait que l'outil ssldump (http://www.rtfm.com/ssldump/) fasse déjà tout ce boulot. Sinon, il est toujours possible de regarder dans le code source d'OpenSSL (http://www.openssl.org/) mais ce code source est crade et peu lisible.
--Thomas Pornin
According to Big joke <choupito2003@yahoo.fr>:
Je pense avoir un problème avec le client et server random.
Question:
Faut-il transformer ces octets de big endian vers little endian?
Non. Ce sont 32 octets complètement anonymes. Même les 4 premiers octets
de "timestamp" sont à traiter comme les autres ; d'ailleurs, rien
n'impose au juste un client de mettre un timestamp correct (en fait, le
standard décrivant SSL/TLS impose au serveur de ne pas s'offusquer même
s'il trouve n'importe quoi en lieu et place du timestamp).
La dérivation des clés (de chiffrement et de MAC) utilise la "PRF"
(pseudo-random function) spécifique à SSL/TLS pour faire le boulot.
Cette fonction va utiliser le random du serveur, celui du client,
et le "master secret". Quelques points importants :
-- Il y a SSL 3.0 et TLS 1.0. TLS 1.0 est en fait SSL 3.1. TLS 1.0 est
standard, et décrit par la RFC 2246. SSL 3.0 n'est pas standard ; on
doit pouvoir trouver un draft sur le site web de Netscape (en cherchant
bien à coups de google). SSL 3.0 et TLS 1.0 n'utilisent PAS la même
PRF. La version utilisée pour un échange donné est celle utilisée
par le serveur dans son "ServerHello".
-- Même si c'est pour faire du SSL 3.0 ou 3.1, certaines implémentations
envoient un ClientHello en SSL 2.0 (mais spécifiant que le SSL 3.0 est
supporté) ; la RFC 2246 indique comment est calculé le "client random"
dans ce cas-là.
-- Pour calculer les clés, on utiliser les deux randoms et le "master
secret". Le "master secret" est lui-même dérivé du "pre-master secret"
(et des deux randoms) avec la PRF. Ce qui veut dire qu'entre le
pre-master secret (le mot de 48 octets commençant par la version et
chiffré en RSA, si le serveur utilise une clé RSA) et les clés de
chiffrement, il y a _deux_ couches de PRF. On en oublie facilement une,
surtout que le "master secret" fait lui aussi 48 octets de long.
-- Ne pas oublier qu'il y a deux clés de chiffrement, une dans chaque
sens. De plus, il faut bien rester synchronisé avec les messages et
ne pas en sauter. Le premier message chiffré dans chaque sens est
un message "Finished", et pas les données directement.
En résumé : c'est compliqué. Il semblerait que l'outil ssldump
(http://www.rtfm.com/ssldump/) fasse déjà tout ce boulot. Sinon,
il est toujours possible de regarder dans le code source d'OpenSSL
(http://www.openssl.org/) mais ce code source est crade et peu lisible.
Je pense avoir un problème avec le client et server random. Question: Faut-il transformer ces octets de big endian vers little endian?
Non. Ce sont 32 octets complètement anonymes. Même les 4 premiers octets de "timestamp" sont à traiter comme les autres ; d'ailleurs, rien n'impose au juste un client de mettre un timestamp correct (en fait, le standard décrivant SSL/TLS impose au serveur de ne pas s'offusquer même s'il trouve n'importe quoi en lieu et place du timestamp).
La dérivation des clés (de chiffrement et de MAC) utilise la "PRF" (pseudo-random function) spécifique à SSL/TLS pour faire le boulot. Cette fonction va utiliser le random du serveur, celui du client, et le "master secret". Quelques points importants :
-- Il y a SSL 3.0 et TLS 1.0. TLS 1.0 est en fait SSL 3.1. TLS 1.0 est standard, et décrit par la RFC 2246. SSL 3.0 n'est pas standard ; on doit pouvoir trouver un draft sur le site web de Netscape (en cherchant bien à coups de google). SSL 3.0 et TLS 1.0 n'utilisent PAS la même PRF. La version utilisée pour un échange donné est celle utilisée par le serveur dans son "ServerHello".
-- Même si c'est pour faire du SSL 3.0 ou 3.1, certaines implémentations envoient un ClientHello en SSL 2.0 (mais spécifiant que le SSL 3.0 est supporté) ; la RFC 2246 indique comment est calculé le "client random" dans ce cas-là.
-- Pour calculer les clés, on utiliser les deux randoms et le "master secret". Le "master secret" est lui-même dérivé du "pre-master secret" (et des deux randoms) avec la PRF. Ce qui veut dire qu'entre le pre-master secret (le mot de 48 octets commençant par la version et chiffré en RSA, si le serveur utilise une clé RSA) et les clés de chiffrement, il y a _deux_ couches de PRF. On en oublie facilement une, surtout que le "master secret" fait lui aussi 48 octets de long.
-- Ne pas oublier qu'il y a deux clés de chiffrement, une dans chaque sens. De plus, il faut bien rester synchronisé avec les messages et ne pas en sauter. Le premier message chiffré dans chaque sens est un message "Finished", et pas les données directement.
En résumé : c'est compliqué. Il semblerait que l'outil ssldump (http://www.rtfm.com/ssldump/) fasse déjà tout ce boulot. Sinon, il est toujours possible de regarder dans le code source d'OpenSSL (http://www.openssl.org/) mais ce code source est crade et peu lisible.
--Thomas Pornin
choupito2003
cool, je crois que tu viens de me donner la solution.
De plus, il faut bien rester synchronisé avec les messages et ne pas en sauter. Le premier message chiffré dans chaque sens est un message "Finished", et pas les données directement.
J'avais effectivement sauté les finish qui ne m'intéressaient pas :-)
Au niveau synchro, tu me confirmes que si je saute un msg, je ne pourrais pas décrypter le suivant? Ceci est vrai que je sois en block cipher ou stream cipher? ( ici RC4 = stream cipher)
Dernière question (j'éspère), les data encryptées extraites de la trace réseau, j'inverse les octets avant de décrypter sur wintel? ( là je fatigue :-))
Pour la génération de clés, je conseille l'excellent livre de Eric Rescorla "SSL and TLS". C'est une bible. Eric est d'ailleurs l'auteur de ssldump.
( Je confirme openssl et ssldump sont bien du code krado :-)).
(Thomas Pornin) wrote in message news:<bg3jeu$tsd$...
According to Big joke :
Je pense avoir un problème avec le client et server random. Question: Faut-il transformer ces octets de big endian vers little endian?
Non. Ce sont 32 octets complètement anonymes. Même les 4 premiers octets de "timestamp" sont à traiter comme les autres ; d'ailleurs, rien n'impose au juste un client de mettre un timestamp correct (en fait, le standard décrivant SSL/TLS impose au serveur de ne pas s'offusquer même s'il trouve n'importe quoi en lieu et place du timestamp).
La dérivation des clés (de chiffrement et de MAC) utilise la "PRF" (pseudo-random function) spécifique à SSL/TLS pour faire le boulot. Cette fonction va utiliser le random du serveur, celui du client, et le "master secret". Quelques points importants :
-- Il y a SSL 3.0 et TLS 1.0. TLS 1.0 est en fait SSL 3.1. TLS 1.0 est standard, et décrit par la RFC 2246. SSL 3.0 n'est pas standard ; on doit pouvoir trouver un draft sur le site web de Netscape (en cherchant bien à coups de google). SSL 3.0 et TLS 1.0 n'utilisent PAS la même PRF. La version utilisée pour un échange donné est celle utilisée par le serveur dans son "ServerHello".
-- Même si c'est pour faire du SSL 3.0 ou 3.1, certaines implémentations envoient un ClientHello en SSL 2.0 (mais spécifiant que le SSL 3.0 est supporté) ; la RFC 2246 indique comment est calculé le "client random" dans ce cas-là.
-- Pour calculer les clés, on utiliser les deux randoms et le "master secret". Le "master secret" est lui-même dérivé du "pre-master secret" (et des deux randoms) avec la PRF. Ce qui veut dire qu'entre le pre-master secret (le mot de 48 octets commençant par la version et chiffré en RSA, si le serveur utilise une clé RSA) et les clés de chiffrement, il y a _deux_ couches de PRF. On en oublie facilement une, surtout que le "master secret" fait lui aussi 48 octets de long.
-- Ne pas oublier qu'il y a deux clés de chiffrement, une dans chaque sens. De plus, il faut bien rester synchronisé avec les messages et ne pas en sauter. Le premier message chiffré dans chaque sens est un message "Finished", et pas les données directement.
En résumé : c'est compliqué. Il semblerait que l'outil ssldump (http://www.rtfm.com/ssldump/) fasse déjà tout ce boulot. Sinon, il est toujours possible de regarder dans le code source d'OpenSSL (http://www.openssl.org/) mais ce code source est crade et peu lisible.
--Thomas Pornin
cool, je crois que tu viens de me donner la solution.
De plus, il faut bien rester synchronisé avec les messages et
ne pas en sauter. Le premier message chiffré dans chaque sens est
un message "Finished", et pas les données directement.
J'avais effectivement sauté les finish qui ne m'intéressaient pas :-)
Au niveau synchro, tu me confirmes que si je saute un msg, je ne
pourrais pas décrypter le suivant?
Ceci est vrai que je sois en block cipher ou stream cipher?
( ici RC4 = stream cipher)
Dernière question (j'éspère), les data encryptées extraites de la
trace réseau, j'inverse les octets avant de décrypter sur wintel? ( là
je fatigue :-))
Pour la génération de clés, je conseille l'excellent livre de Eric
Rescorla "SSL and TLS".
C'est une bible. Eric est d'ailleurs l'auteur de ssldump.
( Je confirme openssl et ssldump sont bien du code krado :-)).
pornin@nerim.net (Thomas Pornin) wrote in message news:<bg3jeu$tsd$1@biggoron.nerim.net>...
According to Big joke <choupito2003@yahoo.fr>:
Je pense avoir un problème avec le client et server random.
Question:
Faut-il transformer ces octets de big endian vers little endian?
Non. Ce sont 32 octets complètement anonymes. Même les 4 premiers octets
de "timestamp" sont à traiter comme les autres ; d'ailleurs, rien
n'impose au juste un client de mettre un timestamp correct (en fait, le
standard décrivant SSL/TLS impose au serveur de ne pas s'offusquer même
s'il trouve n'importe quoi en lieu et place du timestamp).
La dérivation des clés (de chiffrement et de MAC) utilise la "PRF"
(pseudo-random function) spécifique à SSL/TLS pour faire le boulot.
Cette fonction va utiliser le random du serveur, celui du client,
et le "master secret". Quelques points importants :
-- Il y a SSL 3.0 et TLS 1.0. TLS 1.0 est en fait SSL 3.1. TLS 1.0 est
standard, et décrit par la RFC 2246. SSL 3.0 n'est pas standard ; on
doit pouvoir trouver un draft sur le site web de Netscape (en cherchant
bien à coups de google). SSL 3.0 et TLS 1.0 n'utilisent PAS la même
PRF. La version utilisée pour un échange donné est celle utilisée
par le serveur dans son "ServerHello".
-- Même si c'est pour faire du SSL 3.0 ou 3.1, certaines implémentations
envoient un ClientHello en SSL 2.0 (mais spécifiant que le SSL 3.0 est
supporté) ; la RFC 2246 indique comment est calculé le "client random"
dans ce cas-là.
-- Pour calculer les clés, on utiliser les deux randoms et le "master
secret". Le "master secret" est lui-même dérivé du "pre-master secret"
(et des deux randoms) avec la PRF. Ce qui veut dire qu'entre le
pre-master secret (le mot de 48 octets commençant par la version et
chiffré en RSA, si le serveur utilise une clé RSA) et les clés de
chiffrement, il y a _deux_ couches de PRF. On en oublie facilement une,
surtout que le "master secret" fait lui aussi 48 octets de long.
-- Ne pas oublier qu'il y a deux clés de chiffrement, une dans chaque
sens. De plus, il faut bien rester synchronisé avec les messages et
ne pas en sauter. Le premier message chiffré dans chaque sens est
un message "Finished", et pas les données directement.
En résumé : c'est compliqué. Il semblerait que l'outil ssldump
(http://www.rtfm.com/ssldump/) fasse déjà tout ce boulot. Sinon,
il est toujours possible de regarder dans le code source d'OpenSSL
(http://www.openssl.org/) mais ce code source est crade et peu lisible.
cool, je crois que tu viens de me donner la solution.
De plus, il faut bien rester synchronisé avec les messages et ne pas en sauter. Le premier message chiffré dans chaque sens est un message "Finished", et pas les données directement.
J'avais effectivement sauté les finish qui ne m'intéressaient pas :-)
Au niveau synchro, tu me confirmes que si je saute un msg, je ne pourrais pas décrypter le suivant? Ceci est vrai que je sois en block cipher ou stream cipher? ( ici RC4 = stream cipher)
Dernière question (j'éspère), les data encryptées extraites de la trace réseau, j'inverse les octets avant de décrypter sur wintel? ( là je fatigue :-))
Pour la génération de clés, je conseille l'excellent livre de Eric Rescorla "SSL and TLS". C'est une bible. Eric est d'ailleurs l'auteur de ssldump.
( Je confirme openssl et ssldump sont bien du code krado :-)).
(Thomas Pornin) wrote in message news:<bg3jeu$tsd$...
According to Big joke :
Je pense avoir un problème avec le client et server random. Question: Faut-il transformer ces octets de big endian vers little endian?
Non. Ce sont 32 octets complètement anonymes. Même les 4 premiers octets de "timestamp" sont à traiter comme les autres ; d'ailleurs, rien n'impose au juste un client de mettre un timestamp correct (en fait, le standard décrivant SSL/TLS impose au serveur de ne pas s'offusquer même s'il trouve n'importe quoi en lieu et place du timestamp).
La dérivation des clés (de chiffrement et de MAC) utilise la "PRF" (pseudo-random function) spécifique à SSL/TLS pour faire le boulot. Cette fonction va utiliser le random du serveur, celui du client, et le "master secret". Quelques points importants :
-- Il y a SSL 3.0 et TLS 1.0. TLS 1.0 est en fait SSL 3.1. TLS 1.0 est standard, et décrit par la RFC 2246. SSL 3.0 n'est pas standard ; on doit pouvoir trouver un draft sur le site web de Netscape (en cherchant bien à coups de google). SSL 3.0 et TLS 1.0 n'utilisent PAS la même PRF. La version utilisée pour un échange donné est celle utilisée par le serveur dans son "ServerHello".
-- Même si c'est pour faire du SSL 3.0 ou 3.1, certaines implémentations envoient un ClientHello en SSL 2.0 (mais spécifiant que le SSL 3.0 est supporté) ; la RFC 2246 indique comment est calculé le "client random" dans ce cas-là.
-- Pour calculer les clés, on utiliser les deux randoms et le "master secret". Le "master secret" est lui-même dérivé du "pre-master secret" (et des deux randoms) avec la PRF. Ce qui veut dire qu'entre le pre-master secret (le mot de 48 octets commençant par la version et chiffré en RSA, si le serveur utilise une clé RSA) et les clés de chiffrement, il y a _deux_ couches de PRF. On en oublie facilement une, surtout que le "master secret" fait lui aussi 48 octets de long.
-- Ne pas oublier qu'il y a deux clés de chiffrement, une dans chaque sens. De plus, il faut bien rester synchronisé avec les messages et ne pas en sauter. Le premier message chiffré dans chaque sens est un message "Finished", et pas les données directement.
En résumé : c'est compliqué. Il semblerait que l'outil ssldump (http://www.rtfm.com/ssldump/) fasse déjà tout ce boulot. Sinon, il est toujours possible de regarder dans le code source d'OpenSSL (http://www.openssl.org/) mais ce code source est crade et peu lisible.
--Thomas Pornin
pornin
According to Big joke :
Au niveau synchro, tu me confirmes que si je saute un msg, je ne pourrais pas décrypter le suivant? Ceci est vrai que je sois en block cipher ou stream cipher? ( ici RC4 = stream cipher)
En RC4, si on saute ne serait-ce qu'un octet, le déchiffrement ne marche plus. RC4 est un système avec un état, qui dépend initialement de la clé et qui évolue avec chaque octet de flux aléatoire pondu par RC4.
Avec un block cipher, le mode CBC est utilisé. Pour déchiffrer un bloc en CBC, il faut avoir le bloc chiffré précédent. On peut donc "sauter" des messages et reprendre en cours de route, avec un bloc de décalage.
Dernière question (j'éspère), les data encryptées extraites de la trace réseau, j'inverse les octets avant de décrypter sur wintel? ( là je fatigue :-))
Il n'y a pas de question d'ordre des octets à ce niveau. Les systèmes de chiffrement travaillent sur des suites d'octets et la façon de manipuler ces octets est leur problème.
Là où l'ordre des octets intervient, c'est quand on représente un nombre entier en une suite d'octets. Il y a de telles conventions dans les messages de "handshake" de SSL, mais rien de tel pour le chiffrement.
--Thomas Pornin
According to Big joke <choupito2003@yahoo.fr>:
Au niveau synchro, tu me confirmes que si je saute un msg, je ne
pourrais pas décrypter le suivant?
Ceci est vrai que je sois en block cipher ou stream cipher?
( ici RC4 = stream cipher)
En RC4, si on saute ne serait-ce qu'un octet, le déchiffrement ne
marche plus. RC4 est un système avec un état, qui dépend initialement
de la clé et qui évolue avec chaque octet de flux aléatoire pondu
par RC4.
Avec un block cipher, le mode CBC est utilisé. Pour déchiffrer un bloc
en CBC, il faut avoir le bloc chiffré précédent. On peut donc "sauter"
des messages et reprendre en cours de route, avec un bloc de décalage.
Dernière question (j'éspère), les data encryptées extraites de la
trace réseau, j'inverse les octets avant de décrypter sur wintel? ( là
je fatigue :-))
Il n'y a pas de question d'ordre des octets à ce niveau. Les systèmes de
chiffrement travaillent sur des suites d'octets et la façon de manipuler
ces octets est leur problème.
Là où l'ordre des octets intervient, c'est quand on représente un
nombre entier en une suite d'octets. Il y a de telles conventions
dans les messages de "handshake" de SSL, mais rien de tel pour le
chiffrement.
Au niveau synchro, tu me confirmes que si je saute un msg, je ne pourrais pas décrypter le suivant? Ceci est vrai que je sois en block cipher ou stream cipher? ( ici RC4 = stream cipher)
En RC4, si on saute ne serait-ce qu'un octet, le déchiffrement ne marche plus. RC4 est un système avec un état, qui dépend initialement de la clé et qui évolue avec chaque octet de flux aléatoire pondu par RC4.
Avec un block cipher, le mode CBC est utilisé. Pour déchiffrer un bloc en CBC, il faut avoir le bloc chiffré précédent. On peut donc "sauter" des messages et reprendre en cours de route, avec un bloc de décalage.
Dernière question (j'éspère), les data encryptées extraites de la trace réseau, j'inverse les octets avant de décrypter sur wintel? ( là je fatigue :-))
Il n'y a pas de question d'ordre des octets à ce niveau. Les systèmes de chiffrement travaillent sur des suites d'octets et la façon de manipuler ces octets est leur problème.
Là où l'ordre des octets intervient, c'est quand on représente un nombre entier en une suite d'octets. Il y a de telles conventions dans les messages de "handshake" de SSL, mais rien de tel pour le chiffrement.
