Pour gérer vos consentements :

Le chiffrement par TLS victime de… la paresse

Sloth, soit paresse en anglais. C’est le titre que deux chercheurs de l’Inria, Karthikeyan Bhargavan et Gaëtan Leurent, ont choisi pour leur récente étude montrant que les faiblesses connues des algorithmes de hachage SHA-1 et surtout MD5 ont des répercussions bien au-delà des seuls certificats. « En réponse à des attaques démontrées récemment et exploitant des collisions sur des fonctions de hachage, les éditeurs de logiciels ont commencé à organiser le retrait de MD5 et SHA-1 dans les applications tierces utilisant des signatures numériques comme les certificats X.509. Mais, ces fonctions de hachage insuffisamment sécurisées continuent à être exploitées dans diverses constructions cryptographiques présentes dans des protocoles très employés, comme TLS (protocole au centre des échanges HTTPS, NDLR), IKE (protocole d’échange de clef utilisé dans les VPN, NDLR) ou SSH (Secure Shell, NDLR) », relèvent les deux chercheurs.

La raison de cette ‘paresse’ ? Les concepteurs de ces systèmes pensaient jusqu’alors que les attaques par collision, qui permettent d’injecter deux messages différents en entrée de la fonction de hachage et d’obtenir le même résultat, n’étaient pas suffisantes pour mettre en péril l’ensemble de l’édifice. « Notre étude montre que c’est pourtant le cas », résume Gaëtan Leurent. Les deux chercheurs de l’Inria identifient notamment une nouvelle classe d’attaques par collision, affectant la transcription des échanges préliminaires à l’établissement de la communication chiffrée (le handshake en jargon) et affaiblissant « significativement » la sécurité théorique de TLS, IKE ou SSH.

TLS 1.2 remet MD5 en jeu

Les chercheurs démontrent en pratique la faisabilité de deux attaques (même s’ils en répertorient une dizaine au total dans leur billet de blog et leur étude). La première concerne TLS 1.2 et l’authentification des clients, un processus par exemple employé dans les VPN (mais pas dans le HTTPS classique). En pratique, elle peut se traduire par une attaque de type Man-in-the-Middle permettant à un serveur pirate de remplacer le serveur légitime aux yeux d’un client donné. Le prototype de l’attaque montée par Karthikeyan Bhargavan et Gaëtan Leurent utilise un utilitaire de calcul de collision (HashClash) et permet de mettre en œuvre cette attaque en une heure sur une station de travail comportant 48 cœurs. « Nous pensons que cette durée peut être significativement réduite en utilisant une implémentation exploitant pleinement les GPU ou basée sur du matériel dédié à MD5 », notent les deux chercheurs. Ironiquement, la faille concerne uniquement TLS 1.2, et pas les versions 1.1 et 1.0. « Car, dans cette mouture 1.2, on a rajouté un mécanisme permettant la négociation de la fonction de hachage entre le client et le serveur, ce qui remet dans le jeu l’algorithme MD5 », note Gaëtan Leurent. L’attaque des chercheurs de l’Inria repose sur cette faiblesse.

Difficile d’estimer le parc applicatif concerné par cette attaque, qui touche le côté client et non les serveurs. « On sait simplement que les librairies Java pour TLS supportent MD5 et sont donc vulnérables », dit Gaëtan Leurent. Et d’inviter les administrateurs de serveurs sous TLS 1.2 (soit environ 1/3 du parc) à changer leur configuration pour refuser les hachages MD5 et SHA-1 que tenteraient de négocier des clients.

Une contre-mesure insuffisante

La seconde attaque concerne un processus appelé le TLS unique (tls-unique), un mécanisme utilisé par certaines applications (comme des messageries instantanées) quand l’authentification du client n’est pas assurée dans TLS lui-même. Le mécanisme en question est censé éviter les attaques par transmission de crédences, permettant à un client de se faire passer pour celui qu’il n’est pas. « Nous montrons que cette contre-mesure est insuffisante », assure Gaëtan Leurent. L’équipe de l’Inria parvient ici à mettre en place une attaque demandant 20 jours sur une station de travail comportant 4 GPU Nvidia Tesla. « Pour mettre en pratique cette attaque, il faudrait réaliser ce calcul durant la phase de négociation entre client et serveur, précise le chercheur. Ce qui est, sur le plan théorique, tout à fait envisageable : les calculs étant aisément parallélisables. »

TLS 1.3 bannit MD5

Les travaux des deux chercheurs de l’institut français expliquent, en partie, la décision de retrait total de MD5 du standard TLS 1.3, actuellement en cours de finalisation à l’IETF. Dans leurs billets de blog, Karthikeyan Bhargavan et Gaëtan Leurent rappellent que les versions préliminaires de cette version du protocole clef dans la sécurisation des échanges sur Internet prévoyaient d’accepter les signatures MD5. Ce qui aurait permis d’étendre l’attaque par collision mise en évidence sur les clients TLS 1.2, aux clients ET serveurs de la version 1.3. « Considérant que l’authentification des serveurs reste un des objectifs principaux de TLS, cette attaque aurait été dévastatrice », écrivent leurs deux chercheurs, qui pressent les auteurs du protocole de blacklister également SHA-1 au plus vite.

Cet article de recherche s’inscrit dans une longue série de travaux de l’Inria sur la sécurité des protocoles de chiffrement les plus utilisés. L’institut est déjà à l’origine de la mise au jour de la faille LogJam ou de la démonstration pratique des faiblesses de SHA-1. Lutter contre la paresse dans les protocoles, tout un programme !

SHA-1 : Google, Microsoft et Firefox font le ménage dans le HTTPS

Comment la NSA a (probablement) cassé le chiffrement par VPN