Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Logjam : après FREAK, une nouvelle faille dans le chiffrement des connexions

On prend les mêmes et on recommence !
Internet 5 min
Logjam : après FREAK, une nouvelle faille dans le chiffrement des connexions
Crédits : Andrey Shadrin/iStock/Thinstock

Une nouvelle faille de sécurité vient de remonter à la surface : Logjam. Né des cendres de FREAK, elle reprend le même principe de fonctionnement et permet d'établir une connexion chiffrée avec une clé trop petite pour être réellement efficace.

Au début du mois de mars, la faille FREAK secouait Internet, pour plusieurs raisons. Tout d'abord, car elle permettait (et permet toujours) d'intercepter des échanges de données chiffrés entre un serveur et un navigateur. Ensuite car il s'agissait d'un reliquat des années 90 lorsque les États-Unis limitaient l'exportation des systèmes de chiffrements à 512 bits maximum (voir cette actualité pour plus de détail). Bien évidemment, bon nombre de serveurs et de navigateurs avaient été rapidement mis à jour suite à cette découverte.

Il convient néanmoins de relativiser puisqu'il faut procéder à une attaque de type « homme du milieu » pour l'exploiter, et donc être sur le même réseau (un « hot-spot » Wi-Fi par exemple), ce qui n'est pas toujours des plus pratiques. On est loin de la portée de Heartbleed par exemple, qui permettait à n'importe qui de lire des données directement dans la mémoire d'un serveur (identifiant, mot de passe, carte bancaire, etc.).

De FREAK à Logjam, toujours la même histoire de chiffrement « faible »

Mais une faille peut en cacher une autre et voilà désormais qu'il est question de Logjam. Elle est détaillée dans ce document, signé par des chercheurs de l'INRIA de Paris et de Nancy, de l'université de Pennsylvanie, de Johns Hopkins, du Michigan et de chez Microsoft Research. Selon les chercheurs, « cette attaque rappelle FREAK, mais elle est due à une faille dans le protocole TLS plutôt qu'à une vulnérabilité dans son implémentation, et elle cible un échange de clés Diffie-Hellman plutôt que d'un échange de clés RSA ».

Avec la faille FREAK et l'utilisation de la fonction « export RSA », un serveur répond avec une clé RSA de 512 bits, tandis qu'avec Logjam et « DHE_EXPORT », serveur et navigateur procèdent à un échange de clés via le protocole Diffie-Hellman, mais dans des groupes de 512 bits seulement... ce qui n'est pas suffisant pour résister à une attaque. On notera que ce problème avait déjà été évoqué par certains il y a plusieurs mois. La situation n'est donc pas nouvelle, mais elle prend une autre tournure.

Serveurs et navigateurs doivent se mettre à jour

Là encore, le problème concerne les navigateurs et les serveurs : il suffit que l'un des deux n'accepte pas un groupe de 512 bits pour que l'attaque échoue. De plus, et comme avec FREAK, il faut être sur le même réseau pour que cela fonctionne via une attaque de l'homme du milieu, ce qui limite évidemment la portée, mais n'enlève rien à sa dangerosité.

Du côté des navigateurs, Internet Explorer ne semble pas vulnérable si l'on en croit l'outil de test proposé par le site WeakDH.org, mais Chrome et Firefox le sont. Adam Langley, un cryptanalyste qui travaille chez Google, s'est exprimé sur le sujet sur l'un des forums du géant du web : « En se basant sur leur travail, nous avons désactivé TLS False-Start avec Diffie-Hellman dans Chrome 42, qui est la version stable depuis plusieurs semaines maintenant [NDLR : on est passé à Chrome 43 depuis ce matin, mais cela ne change rien sur le principe]. Cette attaque sur les serveurs vulnérables sera un peu plus difficile ».

Logjam

Passer à 1 024 bits minimum, voire mieux à Diffie-Hellman sur des courbes elliptiques

Pour autant, cela n'est pas encore suffisant et Adam Langley ajoute que « le tronc commun du code de Chrome changera afin d'imposer une nouvelle taille de 1024 bits pour Diffie-Hellman. Même si cela entraînera des problèmes pour certains sites, le travail d'aujourd'hui montre que nous ne devrions pas considérer de tels sites comme sécurisés de toute manière ». Il précise que « ce changement est en bonne voie d'être inclus dans Chrome 45 », mais que le calendrier pourrait être plus rapide.

Mais tout cela ne sera probablement qu'une solution temporaire. En effet, les chercheurs à l'origine de la publication de Logjam indiquent qu'un groupe de 1 024 bits peut être « cassé » par un pays ayant suffisamment de moyens (on pense notamment à la NSA qui décrypte à tout-va), et cela ne fera qu'empirer avec le temps. Le cryptographe de Google rejoint cette conclusion : « Un minimum de 1024 bits ne suffit pas sur le long terme. Malheureusement, parce que certains clients ne prennent pas en charge les groupes de DH supérieurs à 1024 bits, et parce que TLS ne négocie pas spécifiquement certains groupes, il serait très problématique de pousser cette limite au-dessus de 1024. Alors que nous approchons de l'élimination du chiffrement RSA sur 1024 bits, nous nous interrogeons de manière plus générale sur la prise en charge des groupes non elliptiques DHE dans TLS ». Cela laisse entendre que cette méthode pourrait disparaitre à terme, en tout cas chez Google.

Il existe en effet une version plus sécurisée de ce protocole : ECDHE pour Elliptic curve Diffie–Hellman (ou bien encore Diffie-Hellman sur des courbes elliptiques). Pour Google, « les serveurs qui utilisent actuellement DHE devraient se mettre à jour et passer à ECDHE. Si cela est impossible, utilisez au moins DHE avec des groupes de 1024 bits et ne soyez pas trop surpris si Chrome commence à utiliser du chiffrement RSA avec votre site dans le futur ».

Un guide des bonnes pratiques et un site pour tester navigateurs et serveurs

Cette recommandation est d'ailleurs également faite par l'équipe de chercheurs qui a mis en ligne un petit guide du déploiement de Diffie-Hellman, ainsi qu'un outil de test. Il recommande de désactiver les fonctions Export Cipher Suites, déployer un système de Diffie-Hellman sur des courbes elliptiques et utiliser un groupe fort et unique pour chaque serveur.

Comme toujours, on devrait voir arriver une série de correctifs dans les prochaines semaines, à la fois côté navigateur et serveur. Cela ne devrait pas tarder puisque les principaux concernés ont été mis au courant avant que la faille ne soit rendue publique.

34 commentaires
Avatar de Loscillo INpactien
Avatar de LoscilloLoscillo- 20/05/15 à 14:04:20

L'INRIA Nancy Grand-Est va sortir chaque année un problème de sécurité ? De mémoire, ils avaient déjà montré quelque chose en 2014. J'attends la suite

Avatar de Edtech Abonné
Avatar de EdtechEdtech- 20/05/15 à 14:10:44

Au taff :

Good News! This site uses strong (2048-bit or better) key exchange parameters and is safe from the Logjam attack.

C'est rare qu'on soit au point ! Etrangement, c'est le seul serveur géré par un collègue développeur et pas par le sys admin :D

On est carrément en ECDHE !

Édité par Edtech le 20/05/2015 à 14:11
Avatar de Glyphe INpactien
Avatar de GlypheGlyphe- 20/05/15 à 14:14:56

Edtech a écrit :

Au taff :

C'est rare qu'on soit au point ! Etrangement, c'est le seul serveur géré par un collègue développeur et pas par le sys admin :D

On est carrément en ECDHE !

Le mieux est encore de retirer DHE complètement et de ne laisser que ECDHE. Ca permet d'avoir le top actuellement et de n'être compatible qu'avec des clients modernes et récents (plus souvent mis à jour).

Édité par Glyphe le 20/05/2015 à 14:15
Avatar de ArhK INpactien
Avatar de ArhKArhK- 20/05/15 à 14:16:17

Fallait-il vraiment traduire le "man in the middle" ? C'est vraiment ridicule "homme du milieu" franchement.

Avatar de Edtech Abonné
Avatar de EdtechEdtech- 20/05/15 à 14:18:32

C'est exactement ce qu'on a fait. En fait, en suivant les recommandations des sites faisant référence dans le domaine de la sécurité, tout est déjà OK depuis longtemps !

Avatar de janiko Abonné
Avatar de janikojaniko- 20/05/15 à 14:18:39

Courbes elliptiques : façon ANSSI ou façon NSA ?

Et c'est facile de dire qu'il n'y a qu'à passer aux navigateurs modernes et récents ; quand tu as des millions de clients, tu es prêt à accepter que 20 ou 30 % de tes clients ne puissent plus accéder à tes services ?

Édité par janiko le 20/05/2015 à 14:21
Avatar de Glyphe INpactien
Avatar de GlypheGlyphe- 20/05/15 à 14:23:40

Pourtant si le site ne supporte plus du tout DHE, tu devrais avoir ce message :

 

Good News! This site is safe from the Logjam attack. It
supports ECDHE, and does not use DHE.

Avatar de Glyphe INpactien
Avatar de GlypheGlyphe- 20/05/15 à 14:25:38

des boites qui ont des millions de clients sur le net on en compte 1000 dans le monde entier à tout casser, et je doute que les seniors chargés de la sécu informatique postent des comms sur NXi ... :windu:

Donc non, mon commentaire ne se destinait pas aux sys admins de Amazon, Paypal, Google, Apple, etc ... :mdr:

Édité par Glyphe le 20/05/2015 à 14:26
Avatar de lysbleu INpactien
Avatar de lysbleulysbleu- 20/05/15 à 14:26:07

Je ne trouve pas ça ridicule, on comprend de quoi on parle et c'est aussi long que l'original.

Avatar de Edtech Abonné
Avatar de EdtechEdtech- 20/05/15 à 14:32:47

Ah, donc ça dû resté activé quelque part :D

Il n'est plus possible de commenter cette actualité.
Page 1 / 4