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

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

On prend les mêmes et on recommence !

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

20/05/2015 6 minutes
34

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

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

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

Serveurs et navigateurs doivent se mettre à jour

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

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

Commentaires (34)


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


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 <img data-src=" />



On est carrément en ECDHE !








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 <img data-src=" />



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).



Fallait-il vraiment traduire le “man in the middle” ? C’est vraiment ridicule “homme du milieu” franchement.


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 !


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 ?


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



&nbsp;



Good News! This site is safe from the Logjam attack. It



       supports ECDHE, and does not use DHE.


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 … <img data-src=" />



Donc non, mon commentaire ne se destinait pas aux sys admins de Amazon, Paypal, Google, Apple, etc … <img data-src=" />


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


Ah, donc ça dû resté activé quelque part <img data-src=" />








Glyphe a écrit :



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 … <img data-src=" />



Donc non, mon commentaire ne se destinait pas aux sys admins de Amazon, Paypal, Google, Apple, etc … <img data-src=" />





T’en as au moins un…&nbsp;<img data-src=" />

&nbsp;

&nbsp;Et puis c’est juste pour mettre en perspective : les GAFA et autres grosses boîtes vont quand même avoir pas mal de boulot avec ces failles à répétition, surtout quand on ne peut pas utiliser la solution “idéale”.



Detrompe toi.. Je ne suis pas senior mais nous avons plusieurs millions de clients.


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

&nbsp;Je trouve pas où tester le navigateur.


@Cedrix @janiko



Vous m’avez mal compris en plus. Retirer DHE ne signifie certainement pas ne plus être compatible avec des anciens clients. (D’ailleurs si on parle vraiment de vieux client, ceux sous Windows XP notamment, DHE n’est presque pas supporté non plus donc bon … ) Supprimer DHE signifie juste rendre les clients les plus récents compatible uniquement avec ECDHE (et donc voir sur du plus long terme).

Rien n’empêche, et c’est ce que tout le monde fait d’ailleurs, moi y compris, de laisser RSA en fin de list de ciphersuites pour toujours rester accessible aux “vieux clients”.



Les GAFA sont une toute autre question, pour certains ils développent carrément un navigateur à eux et quasi tous ont des bibliothèquent TLS patchées avec des modifs maison …


Ce que je constate c’est qu’on a actuellement droit à un accroissement des découvertes de failles autour du SSL mais toujours rien ne bouge pour informer tout citoyen de sa responsabilité dans ce contexte. La situation que l’on tente d’éviter d’un point de vue business en évitant de mettre de côté plusieurs milliers de client risque de se produire prochainement.



On a quand même des browsers avec des sensibilités très différentes et au niveau SSL, on a énormément de composantes à mettre à jour rapidement. (protocoles, ciphers, certificats).


J’espère que tout ce qui est “vieux” dans TLS va disparaitre pour http2. Cela serait dommage d’avoir des algo pourris dés le début, alors que l’on change la base de communication.


Oui. A quand l’intégralité des articles en anglais ? <img data-src=" />


Il a quand même raison. C’est ridicule cette propension française à inventer des mots pour l’IT.



Vous etes les seuls au monde à les utiliser et ca vous complique la vie commerciale !


Rétrocompatibilité. C’est malheureux mais tout le monde ne s’appelle pas Apple.


Vous faites toujours le support pour Win 3.11 ?&nbsp; <img data-src=" />


Non mais IE6 a mis 3 mois à passer à la trappe pour des raisons de service.



On ne peut pas empêcher un client d’avoir accès à ses infos même si il est en tort et que niveau IT c’était un risque.








Cedrix a écrit :



Il a quand même raison. C’est ridicule cette propension française à inventer des mots pour l’IT.




Vous etes les seuls au monde à les utiliser et ca vous complique la vie commerciale !







Il n’y a rien d’inventé. S’ils avaient dit Fenêtres n° 10(Chanel)… mais l’attaque de l’homme du milieu est largement utilisée. Et l’ité n’est pas réservée aux américains.<img data-src=" /><img data-src=" />



Je compatis… <img data-src=" />


Une fois que tu as compris que le risque business est un risque comme l’est le risque technique et que ton business, meme informé, accepte le risque… Il n’y a plus vraiment de problème pour moi.


C’est peut etre vrai mais je ne connais pas tant de langues qui traduisent tous les composants à ce point.



Lorsque je dois me synchroniser avec des partenaires français, j’ai l’impression que l’on ne parle plus du meme produit..








Cedrix a écrit :



Rétrocompatibilité. C’est malheureux mais tout le monde ne s’appelle pas Apple.





backward compatibility <img data-src=" />





Cedrix a écrit :



C’est peut etre vrai mais je ne connais pas tant de langues qui traduisent tous les composants à ce point.



Lorsque je dois me synchroniser avec des partenaires français, j’ai l’impression que l’on ne parle plus du meme produit..





C’est ce qui arrive dans tous les domaines lorsque l’on ne parle pas la même langue : un ébéniste anglais pourrait être perdu en parlant avec un ébéniste français. Et les Québecois, c’est pire, absolument tous les mots sont traduits <img data-src=" />.









Cedrix a écrit :



Rétrocompatibilité. C’est malheureux mais tout le monde ne s’appelle pas Apple.





Euh… je parle de http2, il n’y a pas de rétrocompatibilité à avoir ! C’est tout neuf.









lysbleu a écrit :



C’est ce qui arrive dans tous les domaines lorsque l’on ne parle pas la même langue : un ébéniste anglais pourrait être perdu en parlant avec un ébéniste français. Et les Québecois, c’est pire, absolument tous les mots sont traduits <img data-src=" />.





“Tournez à la 3ème lumière”: j’ai eu un moment de flottement quand on m’a expliqué la route à prendre à Montreal. Il m’a bien fallu 30 secondes pour comprendre où je devais tourner…&nbsp;<img data-src=" />









cyrano2 a écrit :



J’espère que tout ce qui est “vieux” dans TLS va disparaitre pour http2. Cela serait dommage d’avoir des algo pourris dés le début, alors que l’on change la base de communication.





Tu peux vérifier par toi-même mais la liste des ciphers blacklistées est assez importante :https://tools.ietf.org/rfcmarkup?doc=7540#appendix-A & https://httpwg.github.io/specs/rfc7540.html#BadCipherSuites



Un ébéniste a quand même moins de contacts et de documents internationaux comme ca peut être le cas avec un produit middleware. :P








Cedrix a écrit :



Un ébéniste a quand même moins de contacts et de documents internationaux comme ca peut être le cas avec un produit middleware. :P



un logiciel du milieu !



Ridicule ?

Ah oui je vois.

Un français incapable d’exprimer un concept universel dans sa langue maternelle.

Je crois qu’ en France on appelle cela un beauf dès lors qu’ il ne trouve aucune solution pour y parvenir.








fullero a écrit :



Ridicule ?

Ah oui je vois.

Un français incapable d’exprimer un concept universel dans sa langue maternelle.

Je crois qu’ en France on appelle cela un beauf dès lors qu’ il ne trouve aucune solution pour y parvenir.







Oui, ridicule.



Et non, je ne suis pas français, j’ai l’esprit ouvert… :-)



Ca fait seigneur des anneaux. J’ai peur !