Après les deux failles mettant en cause l’utilisation d’instructions goto (l’une chez Apple, l’autre chez GNUTLS) et la faille Heartbleed, une vulnérabilité a encore été découverte : Triple Handshake («Triple poignée de main»), aussi appelée 3Shake.
Contrairement aux autres failles, celle-ci ne concerne pas l’implémentation mais le protocole. Cela signifie qu’elle touche potentiellement toutes les implémentations et que la correction définitive de cette faille nécessiterait une modification dans le protocole. En pratique, les corrections ont été effectuées en faisant des vérifications supplémentaires ou en éliminant certains algorithmes de chiffrement.
Logo par @Raed667
Concrètement, cette faille exploite les différents types de poignées de main (handshake, procédure qui permet d’établir les différents paramètres de communication entre deux machines, étape particulièrement importante pour un protocole de sécurité) afin de se faire passer pour une autre machine et d’effectuer une attaque de l’homme du milieu.
La faille est cependant considérée moins grave que Heartbleed, en partie parce qu’elle est compliquée, s’attaque à une configuration assez spécifique et nécessite une position privilégiée entre deux machines.
Sommaire
Bref historique
Cette faille a été découverte par Antoine Delignat-Lavaud, Karthikeyan Bhargavan et Alfredo Pironti de l’équipe de recherche Prosecco de l’INRIA Paris-Rocquencourt.
Cette découverte s’est faite dans le cadre du projet miTLS, dont le but est de créer une implémentation de référence vérifiée de TLS. Elle est réalisée en F# et, bien qu’encore trop immature pour un environnement de production, est utilisée sur le site web du projet. Ce projet compte également dans son équipe, en plus de membres de l’INRIA, des gens de Microsoft Research et du IMDEA software institute.
La faille a été présentée lors de la 89e rencontre de l’IETF, et un brouillon a été proposé pour corriger le protocole.
Enfin, cette faille est connue depuis au moins octobre 2013 et a été divulguée de façon responsable. Elle a seulement été dévoilée publiquement au début du mois de mars dernier.
Explication de la faille
Fonctionnement des poignées de main
TLS comporte deux sous-protocoles : le protocole d’échange de poignées de main (qui sert à l’authentification et l’échange de clés de chiffrement entre les deux machines) et le protocole d’échange qui utilise ces dernières pour échanger des données de manière sécurisée.
Il existe plusieurs types de poignées de main. Généralement, un client se connecte à un serveur et lui demande son certificat pour vérifier son identité. Mais il est possible que les deux (client et serveur) s’authentifient l’un auprès de l’autre.
Poignée de main de renégociation
TLS prend en charge une poignée de main de renégociation, qui permet de passer d’un mode à un autre, typiquement du mode « serveur authentifié seulement » au mode « client et serveur authentifiés ». Cela arrive par exemple lorsque le client veut accéder à une ressource protégée.
En 2009, une faille utilisant la poignée de main de renégociation a été découverte, permettant d’effectuer une attaque de l’homme du milieu. L’attaquant établissait une connexion non-sécurisée au serveur et, lorsque le serveur demandait une authentification, il pouvait simplement transmettre la poignée de main de renégociation à un client honnête. Le serveur avait alors l’impression que les deux trafics proviennent de la même personne (qui est alors authentifiée).
Pour corriger cela, une poignée de main de renégociation sécurisée a été proposée. Elle consiste à prouver que c’est bien la même personne qui a effectué la précédente poignée de main, en ajoutant un hachage du master secret (secret partagé entre le client et le serveur) et un hachage de la précédente poignée de main.
Des protections insuffisantes
La découverte de la faille 3Shake nous montre que ça n’était pas suffisant.
Dans certains systèmes, lorsqu’on essaie, lors d’une connexion sécurisée, d’accéder à une ressource protégée sur un serveur, le serveur peut demander une renégociation pour que le client s’authentifie lui aussi à l’aide d’un certificat. Cette faille permet, dans cette configuration précise, d’effectuer une attaque de l’homme du milieu.
Étape 1
Le master secret est censé n’être connu que par le client et le serveur et être unique à la connexion. Pourtant, un attaquant malin peut se débrouiller pour établir le même master secret sur deux connexions différentes.
Si le client se connecte par TLS à l’attaquant en pensant qu’il est le serveur, l’attaquant établit en même temps une connexion TLS avec le serveur, et peut alors se débrouiller pour que le client et le serveur utilisent le même master secret (ce qui est plutôt grave pour un secret).
Concrètement, ça se passe comme ça :
- Le client demande la connexion : il envoie des données aléatoires (que l’on appelera ici CR pour Client Random) qui serviront à établir le master secret ainsi que la liste des algorithmes qu’il connait.
- L’attaquant reçoit le CR et le transmet au serveur, mais en indiquant qu’il ne connait que RSA (ou DHE, mais cela ne semble pas fonctionner avec ECDHE).
- Le serveur envoie à l’attaquant le SR (pour Server Random) et le SID (identifiant de session) qui serviront eux aussi à la construction du master secret, et indique qu’il utilise RSA. Ce message est transmis sans modification au client.
- Le serveur envoie son certificat à l’attaquant et l’attaquant transmet son certificat au client.
Il faut noter que si l’attaquant avait transmis le certificat du serveur au client, le client aurait découvert que l’attaquant était un usurpateur en regardant dans sa base de certificat SSL, de la même façon qu’un navigateur web reconnait que le certificat appartient au site visité ou non.
- Le client créé et envoie une pre-master key (calculée à partir du CR, SR et d’autres choses encore), chiffrée avec la clé publique du certificat de l’attaquant, les deux parties génèrent alors le master secret et les clés de session. L’attaquant fait de même avec le serveur.
- Le client envoie un message pour demander au serveur de communiquer avec les clés de session qui viennent d’être créées.
L’attaquant peut communiquer avec le client et le serveur et faire passer les messages, mais le hachage des poignées de main entre le client et l’attaquant et entre l’attaquant et le serveur sont différentes car ça n’est pas le même certificat.
Étape 2
Il existe un autre type de poignée de main : la poignée de main de reprise (resumption handshake). Elle permet d’établir de nouvelles clés cryptographiques entre deux parties qui ont déjà établi un master secret entre eux et qui s’en rappellent. Cette poignée de main n’utilise pas de chiffrement à clé publique ou de certificat pour rendre l’opération plus rapide.
Lorsque le client veut reprendre sa communication, l’attaquant fait la même chose avec le serveur. L’attaquant a alors juste à transmettre les messages du client au serveur et inversement. On arrive au même point que l’étape 1, sauf que le hachage de la poignée de main des deux connexions sont désormais les mêmes.
Étape 3
Le client, en voulant accéder à une ressource qui nécessite une authentification par certificat, va provoquer une poignée de main de renégociation. Étonnamment, le serveur peut changer de certificat au cours de cette poignée de main.
L’attaquant transmet tous les messages de renégociation sans les changer. Sans détailler, c’est à peu près la même chose que l’étape 1 sauf que l’attaquant ne modifie pas le contenu de chaque échange. Du coup, le client a désormais le certificat du serveur et non plus celui de l’attaquant. Ce dernier ne connait alors pas la paire de clés utilisée par le client et le serveur pour communiquer.
À la fin de la renégociation, l’attaquant ne connait plus les clés de session ou le master secret ; ils sont seulement connus du client et du serveur. Par conséquent, l’attaquant ne peut plus lire ou envoyer de messages sur ces connexions. Cependant, ces précédents messages sur les deux connexions peuvent bien être préfixés par les messages envoyés après renégociation. De plus, l’attaquant peut toujours lire et écrire des données sur ces connexions en s’appuyant sur la politique de même origine (same origin policy).
Je vous avoue que moi-même que, malgré tous mes efforts, je n’ai pas bien compris l’intérêt de l’étape 3, ni l’étendue des attaques possibles ensuite.
Corrections appliquées
Apple a fait le communiqué suivant :
Pour empêcher les attaques fondées sur ce cas de figure, Secure Transport a été modifié pour que, par défaut, une renégociation doive présenter le même certificat serveur que celui qui a été présenté lors de la connexion originale. Ce problème ne touche pas les systèmes Mac OS X 10.7 et précédents.
Les autres logiciels (principalement les navigateurs) et bibliothèques qui ont corrigé la faille semblent tous avoir adopté une solution similaire. Certains ont limité les poignées de main à l’algorithme ECDHE.
Est-on vraiment protégé ?
Des implémentations buguées
Si Heartbleed a été très médiatisé, ça n'est ni la première, ni la dernière faille de sécurité qui sera découverte. Pire, on découvre régulièrement de nouvelles failles au sein de bibliothèques implémentant le protocole SSL/TLS et aucune implémentation n’est épargnée. C’est pourtant la base aujourd’hui de la communication « sécurisée » en ligne.
Les gens du projet ClearCrypt par exemple critiquent la qualité du code d’OpenSSL et de NSS. La description d’OpenSSL indique :
OpenSSL : […] Considéré par la communauté de la sécurité comme un énorme tas de merde fumant avec une interface de programmation byzantine et une implémentation surréaliste. Récemment victime de la faille Heartbleed, une erreur de programmation triviale qui permet de récupérer des clés privées. Sujet par le passé à des bugs encore pires, comme une vulnérabilité permettant l’exécution de code arbitraire à distance.
Et celle de NSS est dans le même style.
Un mauvais protocole ?
Mais cette faille remet également en cause la sécurité du protocole lui-même, pourtant utilisé et audité depuis des années. L’équipe qui a découvert la faille a fait une liste des fonctionnalités vulnérables qui ont permis à la faille d’exister. Et si TLS n’était pas si génial que ça ?
C’est en tout cas l’avis du cryptographe Matthew Green :
J’aime beaucoup TLS, mais le protocole est un sérieux bazar. Sur certains points, il hérite d'un sacré paquet de cryptographie de ses prédécesseurs (SSLv1–3). Pour d’autres, c’est seulement le véritable début d’une analyse formelle et rigoureuse.
et des gens du projet ClearCrypt :
[…] TLS est une putain de magie noire et réaliser une nouvelle implémentation de TLS interopérable peut seulement être fait par des magiciens de ce type de magie noire.
Le projet ClearCrypt
C'est pourquoi ce dernier veut remédier aux deux problèmes à la fois : implémenter un protocole plus sûr que TLS avec un langage très sûr. La complexité du format de certificat X.509 est aussi remise en question, notamment le fait que ce ne soit pas un format lisible par un humain, et que le format est vraiment complexe et alambiqué.
Un des protocoles étudié et discuté est une variante TCP de CurveCP (qui utilise à la base UDP). Le protocole Tcpcrypt est aussi mentionné, qui permettrait de chiffrer la couche transport et une partie de la couche réseau. Le langage Rust est envisagé pour l’implémentation car c’est un langage système et que sa gestion mémoire est sûre.
Pour plus d’informations, voir ici.
Conclusion
Les failles découvertes ces derniers temps nous rappellent que ni le protocole, ni les implémentations ne sont infaillibles. Il est peut-être temps d’analyser plus en profondeur TLS ou de penser à utiliser un autre protocole (un potentiel TLSv2 ou un tout autre protocole), mais aussi de promouvoir et utiliser les outils qui permettent d’obtenir du code sûr.
# Pas grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Vu l'étape 1, cette faille n'est vraiment pas problématique :
Notez cette dernière sous-étape : à ce moment-là, le client s'aperçoit que le certificat ne correspond pas au nom du serveur auquel il essaie de se connecter, détecte donc une possible attaque MiTM, et abandonne la connexion.
Cette attaque ne peut donc se faire que dans un des cas suivants :
Bref, c'est une faille qui semble simplement aggraver un cas classique d'attaque MiTM.
[^] # Re: Pas grave
Posté par claudex . Évalué à 4.
Pas du tout. Si j'ai bien compris. Tu te connecte sur https://example.com mais c'est un site malicieux qui forward tes informations sur https://example.org, cela va permette au gestionnaire de https://example.com de faire une attaque sur https://example.org sans que tu le sache.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas grave
Posté par Ramillien Florian . Évalué à 1.
Vraiment "pas grave" pour la majeur partie des utilisation de TLS.
Qui utilise actuellement l'authentification du client par bi-clé et certificats ?
J'ai déjà utilisé ce type d'authent mais sur des environnements assez contrôlé : entre serveurs.
Mwha
[^] # Re: Pas grave
Posté par claudex . Évalué à 8.
C'est utilisé par StartSSL pour identifier les clients il me semble.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -3.
Super, donc en gros il faut que l'utilisateur se connecte sans faire exprès à un site qui ressemble disons, à celui de sa banque, mais qui n'a pas le même nom, et qu'il se comporte comme si c'était vraiment le site de sa banque ? Dans ce cas, la faille principale exploitée n'est pas dans le client, ni dans le serveur, mais entre la chaise et le clavier.
[^] # Re: Pas grave
Posté par claudex . Évalué à 5.
En fait, tu fais exprès de ne pas comprendre ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Non, je dois vraiment avoir loupé quelque chose, parce que ce que je lis de l'explication a l'air très clair : le client se connecte à l'attaquant en pensant qu'il s'agit du serveur, et celui-ci lui fournit son propre certificat à la place de celui du serveur. Il s'agit là du scénario le plus classique de MiTM, qui est irréalisable avec une utilisation normale de TLS, et qui nécessite soit la corruption d'une autorité de certification soit une négligence grave de la part de l'utilisateur.
[^] # Re: Pas grave
Posté par gouttegd . Évalué à 3.
Pas si irréalisable que ça, vu que le navigateur vérifie uniquement que le certificat présenté par le serveur est bien signé par une autorité de certification « de confiance ». Il suffit donc à l’attaquant d’obtenir un certificat signé par une des (centaines de) CA présentes dans le magasin des navigateurs.
Ou de s’adresser à une CA peu regardante…
[^] # Re: Pas grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
C'est ce que j'appelle la corruption d'une autorité de certification : l'amener, quel que soit le moyen, à émettre un certificat pour un nom différent du sien propre. Et non, ce n'est pas forcément très difficile, mais là encore, il s'agit d'une faille qui n'a rien de spécifique avec le cas de la triple poignée de main donc on parle ici.
[^] # Re: Pas grave
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Tu ne te rappelles pas lorsque la Tunisie faisait des clones des formulaires d'identification de Gmail/Yahoo/Facebook avec le vrai domaine et un certificat et tout et tout ?
Pour l'histoire, ça c'était remarqué à cause de messages de debug du EasyPHP utilisé (et aucun de ces trois grands ne sont assez tarés pour mettre un EasyPHP en production), mais quand un gouvernement a le pouvoir de rediriger un nom de domaine tiers sur son propre serveur et d'être autorité de certification pour ce domaine tiers, la faille n'est pas entre la chaise et le clavier du citoyen.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas grave
Posté par freem . Évalué à 4.
Ce qui est dit dans je journal, c'est que ça ne cible que des configuration précises. Il me semble qu'il y avait assez d'emphase le sur le fait que cette faille est compliquée à exploiter à cause de ce fait d'ailleurs?
[^] # Re: Pas grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Bon, je crois que je viens de comprendre. Le départ de l'attaque n'est pas ce que je pensais : ici, le client se connecte volontairement à l'attaquant, qui ne dissimule pas son identité, par exemple parce qu'il fournit un service particulier, sans savoir que celui-ci va tenter une attaque.
Ensuite ou en parallèle, l'attaquant se connecte à un serveur dont le client est également utilisateur.
Enfin, l'attaquant bidouille ses deux connexions — avec le client et avec le serveur attaqué — de façon à obtenir une situation où il peut se faire passer pour le client auprès du serveur.
[^] # Re: Pas grave
Posté par claudex . Évalué à 6.
C'est ce que je disais là https://linuxfr.org/news/triple-poignee-de-main-faille-dans-le-protocole-ssl-tls#comment-1536979
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas grave
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Vu qu'un gouvernement (qui en fait la demande à Microsoft) est CA dans Internet Explorer pour le monde entier, si le pirate est également l'état, ce sont juste des millions de citoyens qui sont vulnérables.
Par contre je n'ai pas compris ce que cette faille permet de plus que ne le permet un fishing des familles comme on a déjà vu avec un faux Facebook/Gmail/Yahoo, Internet Explorer et le CA Tunisien ^^.
Est-ce que cela permettrait à terme d'écouter en clair une conversation entre un utilisateur et un serveur sans prendre la place de l'un ou de l'autre en dehors d'un instant précis et unique de la poignée de main (et une fois pour toute) ?
ce commentaire est sous licence cc by 4 et précédentes
# Tcpcrypt
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est une extension à TCP (je ne savais pas que cela existait) donc a priori compatible (sinon projet mort né). A noter que pour le moment, cela ne marche pas avec IPv6. Sinon, ca a l'air effectivement intéressant ces pistes..
# Microsoft...
Posté par gyom gyom . Évalué à -9.
"Elle est réalisée en F# […]"
Y'a que moi qui avait deviné la suite :
"des gens de Microsoft Research […]"
Nan parce que bon F#, y'a que des gens de chez M$ pour l'utiliser ce langage… C'est pas pour rien qu'ils l'ont "abandonné"…
http://linuxfr.org/users/armorique/journaux/microsoft-lib%C3%A8re-f
[^] # Re: Microsoft...
Posté par xcomcmdr . Évalué à 10.
"M$" c'est vraiment éculé comme "blague"…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Microsoft...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 4.
Ce n'est pas une blague, c'est une référence.
[^] # Re: Microsoft...
Posté par eingousef . Évalué à 10.
Tu devrais changer d'avatar avant de donner des leçons aux autres sur les blagues éculées.
*splash!*
[^] # Re: Microsoft...
Posté par j_m . Évalué à 1.
Je crois que tu ne connais rien à la mode ;-)
# HyperCrypt
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Les gens du projet HyperCrypt, par exemple, critiquent la qualité du code de ClearCrypt. La description de ClearCrypt indique :
L'avis des gens de HyperCrypt :
Le projet HyperCrypt
HyperCrypt va être réaliser en Ada parce que c'est hyper plus sécurisé et le C c'est un langage tout pourri pour faire de la sécurité y'a qu'à regarder OpenSSH qui enchaîne faille sur faille et qui met en péril quotidiennement le monde Libre que ça fait même pleurer Blake et Mortimer.
Les certificats tout pourri X.509 seront dans un nouveau format grammar free, context free, word free afin que les chiens, les humains et la plantes carnivores d'appartement du premier étage puissent les lire quand ils s'emmerdent vraiment devant leur ordi.
Le protocole sera basé sur StraightXZ qui démontre un perte totale des paquets en cas de congestion réseau mais ça a été écrit par un grand nom de la sécurité alors c'est trop génial.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: HyperCrypt
Posté par ariasuni . Évalué à 3.
Ils n’ont pas écrit de code, tout n’est qu’à l’état de réflexion, si ça se trouve la sauce ne prendra pas. Il y a seulement une liste de diffusion et un site web pour le moment.
Ça c’est CurveCP qui de base se fonde utilise UDP, mais ils parlent de faire une implémentation généraliste qui se base sur TCP (il existe déjà des implémentations non-généralistes sur TCP qui fonctionnent, cf. le site de ClearCrypt).
Sinon j’ai bien rigolé quand même. :D
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HyperCrypt
Posté par Tonton Th (Mastodon) . Évalué à 5.
Chic, une liste !
# Rust
Posté par David Demelier (site web personnel) . Évalué à 1.
Génial personne va s'en servir \o/. Ou alors il reste à espérer qu'ils fassent au moins une interface C.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Rust
Posté par claudex . Évalué à 6.
C'est une fonctionnalité intégrée au langage, ce serait dommage de s'en privé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.