Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

De nombreux sites web sont vulnérables à Logjam
Une nouvelle faille de sécurité dans le protocole SSL

Le , par Michael Guilloux

0PARTAGES

2  0 
Une nouvelle faille de sécurité a été découverte dans le protocole SSL (Secure Sockets Layer) par des chercheurs de Microsoft Research, des universités de Pennsylvanie, Johns Hopkins, du Michigan et l’institut français de recherche INRIA. Comme la faille FREAK découverte en Mars dernier, la nouvelle faille baptisée Logjam serait le résultat d’une mesure du gouvernement US dans les années 90, interdisant l’expédition de produits logiciels qui utilisent des clés de chiffrement fort. Cette loi adoptée dans le cadre de la sécurité nationale a alors conduit à l’utilisation de clés de 512 bits ; et même après son abolition, de nombreux navigateurs ont continué à utiliser ce type de chiffrement faible pour assurer la sécurité des données.

Par une attaque man-in-the-middle, un pirate peut intercepter la négociation de connexion sécurisée entre un navigateur et un serveur web ou de messagerie. A cette étape, c’est en principe l’algorithme le plus puissant qui doit être utilisé pour chiffrer la connexion. Mais en utilisant la faille Logjam, le pirate peut parvenir à tromper le serveur web en utilisant une clé de 512 bits, plus facile à craquer. Les données faiblement chiffrées qui sont envoyées par le navigateur peuvent être alors décodées en quelques minutes, explique Matthew D. Green, l’un des chercheurs qui ont découvert la faille.

La faille se situe au niveau d’un algorithme appelé « Diffie-Hellman key exchange » qui permet à des protocoles de négocier une clé partagée et de créer une connexion sécurisée.

Les sites web, les serveurs de messagerie et autres systèmes qui supportent les chiffres DHE_EXPORT sont vulnérables à Logjam. La faille a existé depuis plus de deux décennies, explique Green ; et pour l’exploiter, l’attaquant a besoin d’être sur le même réseau que la victime.

Logjam a été discrètement communiqué aux éditeurs de navigateurs. Si Microsoft a corrigé son navigateur Internet Explorer la semaine dernière, des correctifs pour d'autres logiciels tels que Firefox et le navigateur Safari d'Apple devraient être publiés très bientôt.

Environ 7% des sites web sont vulnérables à Logjam, avec jusqu'à 8,4% des sites du top 1 million de domaines. Mais il semble que le plus gros problème se pose avec les serveurs de messagerie. « Le gros problème est que les logiciels que les gens utilisent pour exécuter des serveurs de messagerie ne sont pas aussi bien entretenus, » a dit M. Green. « Ils les installent simplement et les oublient. Un grand nombre de configurations par défaut qui sont expédiées avec [ces logiciels] sont mauvaises. » A-t-il ajouté.

Le taux de vulnérabilité à Logjam a été réduit alors que des mesures ont déjà prises pour corriger la faille FREAK. Le rapport de sécurité note en effet que les organisations et entreprises qui ont patché leur logiciel contre FREAK ne seront pas vulnérables à Logjam, étant donné que ces patchs ont éliminé la possibilité pour les logiciels d'utiliser les chiffres plus faibles.

Sources : Description de la faille Logjam, Rapport de sécurité (pdf)

Et vous ?

Qu’en pensez-vous ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de dahtah
Membre éclairé https://www.developpez.com
Le 22/05/2015 à 0:01
Citation Envoyé par Neckara Voir le message
Bonjour,
Dans la description de la faille faite ici, je ne vois rien de nouveau.
Il est en effet possible de faire un "MITM" pour forcer l'utilisation d'algorithmes ou de clés "faibles", mais des hash signés (?)* sont échangés entre le client et le serveur pour vérifier l'intégrité des messages échangés précédemment.
Oui, Finished, fait un hash de tous les messages échangés, et s'en sert pour demander 12 octets a la fonction pseudo aleatoire (PRF). Le client/serveur verifie qu'ils ont bien les memes 12 octets. Le truc c'est que la PRF est initialisee via les nonces client et serveur (en clair), ainsi que la PMS (pre master key). La PMS est généré a partir des paramètres DH.

Ici les parametre DH sont de taille réduite, du au MITM. Cela permet de retrouver la PMS (offline, ou inline grace a une DB pre-construite sur les paramètres utilisés par DHE), et donc de générer un verify_data (Les fameux 12 octets) valide.

Citation Envoyé par Neckara Voir le message

Je présume donc que la faille est liée au calcul de ces MAC ?
Pas de faille dans le MAC, ni dans la crypto. Le fait que les serveurs supportent la crypto export, ne génère des paramètres éphémères qu'une fois au démarrage et que les clients acceptent des clés de tailles réduites.

Le problème, c'est que les ciphers ne définissent pas la taille des paramètres DH. Si tu utilise TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, tu ne sais pas quelle taille vont faire les paramètres DH. Le serveur choisi. Du coup, en tant que client tu ne peux pas savoir si tu reçois des clés de taille correctes. Tu dois juste accepter des clés qui ont une sécurité "suffisante" (512bits/768bits a éviter, 1024bits serait potentiellement compromis (avec de grosse capacité de calculs, suivez mon regard) pour certains groupes).
2  0 
Avatar de psylox
Membre actif https://www.developpez.com
Le 21/05/2015 à 9:10
Et au niveau des sources je rajouterai pour les sysadmins ou autres personnes gérant un serveur : https://weakdh.org/sysadmin.html

Edit:
Par contre pour apache je préfère: SSLCipherSuite TLSv1:+HIGH:!SSLv2:!MD5:!MEDIUM:!LOW:!EXP:!ADH:!eNULL:!aNULL
qui est plus concie et me semble t-il plus secure.

Enjoy.
1  0 
Avatar de Arnard
Membre émérite https://www.developpez.com
Le 21/05/2015 à 9:35
Si on utilise openSSL, on est également concerné ? Car ici on ne parle que de navigateurs...
0  0 
Avatar de miky55
Membre averti https://www.developpez.com
Le 21/05/2015 à 11:51
Citation Envoyé par Arnard Voir le message
Si on utilise openSSL, on est également concerné ? Car ici on ne parle que de navigateurs...
Tu as du lire l'article en diagonale: il ne parle pas uniquement de navigateur, la faille est en fait des 2 cotés pour qu'elle soit exploitée il faut que le site utilise le protocole d'echange DHE_EXCHANGE et que le navigateur accepte des clés de 512 bits (pour ce même protocole), l'attaquant qui se trouve connecté au réseau local de la victime va lui forcer la main et l'obliger à utiliser la clé la plus faible pour ensuite la cracker.

Pour finir une installation openssl qui accepte des clés inférieur à 1024 bits pour ce protocole est vulnérable. Tu peux vérifier si ton navigateur est vulnérable ici: https://weakdh.org tu peux également trouver des infos sur comment sécuriser ton serveur sur le même site.
0  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 21/05/2015 à 20:24
Bonjour,

Dans la description de la faille faite ici, je ne vois rien de nouveau.
Il est en effet possible de faire un "MITM" pour forcer l'utilisation d'algorithmes ou de clés "faibles", mais des hash signés (?)* sont échangés entre le client et le serveur pour vérifier l'intégrité des messages échangés précédemment.

Je présume donc que la faille est liée au calcul de ces MAC ?
Serait-il possible de savoir en quoi consiste exactement la faille ?

* Je reconnais que je ne me souviens plus vraiment en détail comment est calculé l'intégrité.

EDIT : Je viens de trouver une explication : https://blog.cloudflare.com/logjam-t...ity-explained/
0  0