La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: corrector le 10 mars 2014 à 02:07:23
-
Je poste cette information ici même s'il n'y a pas à proprement parler un problème de cryptographie. Je veux décrire un peu le contexte d'une faille de sécurité.
Comme il y a une faille exploitable grave, ceux qui ont une version vulnérable de iOS ou OS X doivent bien sûr s'assurer d'être à jour sans attendre de comprendre les détails. Mais avant de mettre à jour, mieux vaut s'assurer qu'on utiliser une connexion Wifi sécurisée, sur sa propre box Internet.
Pour ceux qui n'ont pas encore entendu parler du gros #FAIL de la bibliothèque TLS utilisée aussi bien par iOS (le système et les applications) et OS X, surnommée faille "goto fail;"
Résumé :
Il s'agit d'une faille critique très grave, très facilement exploitable du client TLS permettant une attaque MITM (Man In The Middle) sans créer la moindre alerte au niveau de l'application.
"MITM d'une connexion TLS" implique :
- l'attaquant est capable de lire les messages échangés
- l'attaquant est capable de modifier des messages, d'ajouter ou de supprimer des messages échangés
En pratique, si une attaque MITM avait lieu contre le site HTTPS lafibre.info :
- un attaquant pourrait voir les données échangées lors de la phase de login (sur la plupart des sites HTTPS, cela inclut le mdp (mot de passe) en clair, mais pas sur lafibre.info)
- un attaquant peut récupérer le témoin de connexion (le cookie HTTP)
donc
- un attaquant pourrait essayer de casser vos mdp lafibre
- un attaquant pourrait poster des messages en votre nom sur lafibre
-
Prérequis pour effectuer ce type d'attaques :
- être sur le chemin des paquets IP, afin d'intercepter une connexion TCP; si vous n'êtes pas sur le chemin, vous n'avez aucun moyen de voir les segments TCP et donc d'effectuer l'attaque;
- intercepter ces paquets pour les remplacer par d'autres.
Il ne suffit pas de voir les paquets envoyés par le périphérique Apple : il faut les récupérer afin de les traiter, et en envoyer d'autres à la place, comme un proxy transparent (comme le filtre contrôle parental Web de certaines box).
Un moyen d'avoir cette position est de prendre le contrôle d'un routeur personnel, sachant que beaucoup de ces routeurs n'ont pas une sécurité optimale; un autre moyen est de proposer un accès Wifi à Internet, ce qui vous met d'office en position d'intermédiaire (n'oubliez pas ça que quand vous utilisez un accès fournit pas quelqu'un que vous ne connaissez pas).
C'est le prérequis pour toute attaque de type MITM.
-
Rappel sur TLS, le protocole de sécurisation de la couche de transport :
Ceci est un aperçu assez simpliste faisant l'impasse sur les subtilités du protocole. En réalité, il y a plusieurs types de messages, de la signalisation, des changements de clefs, etc. Le but est de rappeler les "étapes clefs" d'une connexion TLS.
Comme ceci n'est pas un cours de cryptographie, je ne vais pas expliquer le fonctionnement des primitives cryptographique ni la façon de les assembler, ni rappeler les principes de la cryptographie asymétriques et de la cryptographie symétrique, des fonctions de hachage cryptographique.
- Le client doit vérifier que le serveur auquel il s'est connecté est autorisé à faire serveur TLS pour ce site.
- le client TLS obtient la clé publique du serveur TLS;
- il vérifie que cette clé correspond à un serveur TLS pour le nom donné (ici "lafibre.info"); plus précisèment, il vérifie une chaîne de signatures cryptographiques, depuis une racine de confiance (aussi appelée ancre de confiance) (ici : le certificat de confiance appartenant à StartCom, auquel nous faisons aveuglèment confiance) (*) jusqu'à la clé publique du serveur (la clé publique de lafibre).
(*) le nombre d'ancres de confiance, leur corruptibilité, et les délégations multiples, posent problème, mais ce n'est pas le sujet ici
Tout ce processus de validation utilise uniquement la cryptographie asymétrique c'est à dire la cryptographie à clé publique/clé privée. (Je ne vais pas entrer dans les détails techniques de cette validation qui ne sont pas en cause ici.)
Disons tout de même que ce processus nécessite de décoder des certificats qui sont dans un format binaire pas franchement simple (ASN.1), de vérifier de nombreux critères de validité des certificats, à commencer par
- les dates de validité,
- le type de certificat (si c'est une autorité),
- les restrictions de délégation d'autorité (certaines délégations peuvent être restreintes en terme de suffixe)
- les restrictions d'usage (p.ex. un certificat de signature de messages courriels ne peut pas être utilisé pour authentifier un site),
et que le moindre bug sautant une étape dans cette validation serait critique (et historiquement on a trouvé des bugs sérieux dans ce processus, dans des logiciels aussi "confidentiels" que IE).
Les données prouvant la validité de la clé du serveur sont envoyées en clair au client. Jusqu'ici, le serveur n'a rien à aucune vérification.
- Le client et le serveur se mettent d'accord sur les paramètres de la connexion sécurisée :
- la version du protocole (lafibre : TLS 1.0)
- une méthode se sécurisation des messages, qui se compose :
- d'une méthode de chiffrement symétrique (lafibre : RC4 avec clé de 128 bits)
- d'une méthode de chaînage (lafibre : pas de chaînage en RC4)
- d'une méthode de contrôle d'intégrité des messages utilisant une fonction de hachage cryptographique et une clé privée (lafibre : basé sur SHA1)
- une méthode de transmission des clefs symétriques entre le client et le serveur (lafibre : RSA); la transmission sécurisée des clé est évidemment essentielle, puisque si cette étape était compromise un adversaire pourrait récupérer les clefs symétriques qui sécurisent les échanges de messages
Jusqu'ici tout se fait en clair, et il n'y a aucun calcul cryptographique ici.
- Le but de tout ce processus étant bien sûr d'utiliser des clefs secrètes (et différentes dans chaque direction) pour chiffrer les données, on va générer ces clefs et les échanger de manière sécurisée. Il y a plusieurs façons de faire, plus ou moins sures. (lafibre : le client va chiffrer utiliser la clé publique RSA du serveur pour lui envoyer une clé symétrique, le serveur utilise la clé privée RSA pour la déchiffrer).
C'est là que les calculs cryptographiques lourds ont lieu coté client et serveur.
À la fin chaque extrémité dispose des mêmes clefs secrètes, et personne d'autre ne peut les connaitre; on peut donc utiliser ces clefs pour échanger des messages.
-
La confidentialité persistante
C'est un concept très important pas toujours bien compris même parfois pas les informaticiens; je préfère citer WP :
La confidentialité persistante (forward secrecy en anglais), est une propriété en cryptographie qui garantit que la découverte par un adversaire de la clé privée d'un correspondant (secret à long terme) ne compromet pas la confidentialité des communications passées.
Elle peut être fournie, par exemple, par la génération des clefs de session au moyen du protocole d'échange de clés Diffie-Hellman. Ces clés de session (temporaires) ne pourront pas être retrouvées à partir des clés des participants, et inversement.
Lors d'une connexion TLS, le choix des algorithmes d'échange de clé permet ou ne permet pas de profiter d'une confidentialité persistante. Les méthodes 'DH' ou 'Ephemeral DH', lorsqu'elles sont utilisées, fournissent une telle caractéristique.
Cela signifie que, même si vous avez obtenu la clé privée du serveur en soudoyant un administrateur, en la volant, ou même grâce à une décision de justice, vous ne serez pas en mesure de déchiffrer les échanges que vous auriez pu enregistrer dans le passé.
Source : Wikipédia : Confidentialité persistante (https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante)
Contrairement à des idées absurdes mais tenaces, la confidentialité persistante ne veut pas dire que si l'adversaire arrive à récupérer la clé privée du serveur, il y a la moindre possibilité de se protéger d'une attaque active (typiquement MITM) de sa part. Tout le système d'authentification du serveur repose sur l'inviolabilité de la clé privée. Une fois la clé privée compromise, il est impossible de savoir si on a affaire au vrai serveur TLS.
La confidentialité persistante implique juste que je n'ai pas une deuxième chance d'attaquer l'établissement d'une connexion TLS :
- ou bien, une attaque MITM a été faite avec succès au bon moment afin de corrompre la crypto ou d'utiliser une clé "volée"
- ou bien, je regarde passer les paquets comme une vache regarde passer le train : sans savoir ce qu'il y a dedans. J'ai laissé passer ma chance, et enregistrer le trafic chiffré n'y fera rien.
En pratique, la confidentialité persistante signifie que si la NSA enregistre tous les échanges chiffrés qui ont lieu, et ensuite pirate ou obtient légalement les clefs privées de tous les serveurs TLS, elle ne peut strictement rien faire de ses enregistrements de données chiffrées (sauf bien sûr si elle dispose de LA machine à décrypter les communications absolue, mais je n'y crois pas une seconde).
lafibre.info n'a pas la confidentialité persistante, donc je ne vais plus pouvoir prendre cet exemple. Google propose la confidentialité persistante.
-
Oubliez donc lafibre.info qui n'est pas un exemple pertinent ici. Oubliez ce qu'on a dit sur l'initialisation d'une connexion TLS parce que c'est pas vrai, c'est plus compliqué.
....
(suite au prochain numéro)