L’IETF vient donc d’annoncer la validation de la modification apportée à la RFC du protocole TLS, comme nous le révèle Marsh Ray sur son blog. En résumé, il s’agit de la correction au protocole telle qu’elle avait été proposée initialement. Elle devra être appliquée tant sur les serveurs (les serveurs Web notamment) que sur les clients (vos navigateurs). Vous risquez donc de voir apparaître dans le futur des messages d’avertissement sur des connexions vers des serveurs en https:// dont la sécurité n’aura pas encore été renforcée.

Cliquer sur l'image pour aller vers l'article

Beaucoup de spécialistes ont rapidement souligné que cette vulnérabilité ne devrait pas avoir d’application facile dans la vie réelle. Malheureusement il semble qu’il faille effectivement la prendre au sérieux. En effet, Anıl Kurmuş, jeune chercheur en sécurité Suisse, a rendu public une démonstration (il l’annonçait mercredi 11 novembre sur Full Disclosure) de la possibilité d’exploiter cette attaque sur Twitter.

Le principe sous-jacent est assez simple puisqu’il repose sur la fonctionnalité même de Twitter qui vise à laisser l’utilisateur publier n’importe quoi. Il a suffi à Anıl Kurmuş de détourner l’API (interface de programmation) de Twitter pour publier en lieu et place du message une partie du cookie, qui contient systématiquement le mot de passe codé, dans le cas de Twitter:

Démonstration d'Anil Kurnus

Il ne reste plus qu’à décoder l’identification qui est ici transmise en Base 64 (ou à la réutiliser telle qu’elle !). Twitter aurait depuis le 10 novembre corrigé la faille. On peut suivre l’évolution des publications des mises à jour des applications concernées par la faille de re-négociation SSL/TLS sur le site de Phonefactor, pour l’instant une version mise à jour d’OpenSSL 0.9.8l bloque déjà la fonction de re-négociation, en attendant un correctif plus pointu.

Histoire récente de la découverte de la faille

Marsh Ray annonce sur son blog qu’il aurait découvert cette faille lors de travaux pour sa société Phonefactor. Les premiers cercles ont été informés de cette découverte au début septembre 2009 et une réunion s’est tenue le 29 septembre 2009 à Mountainview, CA. Nom de code utilisé par le groupe qui s’est donné pour mission de corriger cette faille: “Project Mogul”.

Hier, 4 novembre 2009, Martin Rex (SAP) a présenté publiquement sur la liste de discussion TLS de l’IETF une idée approchante et depuis l’annonce à commencé à faire le tour des blogs et autres twitts.

Description de la faille

La faille porte sur les phases de re-négociation entre le client et le serveur.

Les étapes du dialogue TLS (entre un client et un serveur):

• Le client dit bonjour et indique les technologies de chiffrement acceptées,
• Le serveur répond et précise quelle technologie de chiffrement il préfère, il joint un certificat de chiffrement et indique qu’il a fini la phase de premier contact,
• Le client calcule une clé de chiffrement, la transmet de façon sécurisée grâce au certificat fourni par le serveur et lance une commande Change Cipher Spec pour activer le chiffrement,
• A partir de ce moment tous les messages échangés sont chiffrés.

Le protocole permet à chacune des parties à l’échange de demander une re-négociation à n’importe quel moment.

Les scénarios d’attaque décrits par Marsh sont les suivants:

1. Lors de l’authentification des clients sur la base de certificats,
2. Lorsque le serveur nécessite plusieurs technologies de chiffrement,
3. Lors d’une re-négociation initiée par le client (fonctionne sur des serveurs Apache).

Dans tous les cas, il s’agit pour l’attaquant placé en “man in the middle” d’insérer des commandes au début du dialogue (donc avant le chiffrement) qui seront rejouées au moment de la re-négociation. Et cela même si la re-négociation passe dans le canal chiffré.  Ainsi, si le texte inséré au début est fabriqué de façon intelligente, il permet d’imaginer différentes solutions pour contourner le chiffrement (dans les exemples donnés, il s’agit d’insérer une commande de chargement d’une page web malicieuse et une commande pour ignorer ce qui suit, c’est-à-dire la requête normale du client).

Code inséré

Et maintenant ?

Il aurait été démontré qu’aussi bien Apache qu’IIS de Microsoft étaient sensibles selon les cas à ces attaques. Il n’est pas certain que toutes les situations aient été explorées. Même si un tel mécanisme est très complexe à mettre en œuvre en pratique (les attaques de type man in the middle sont complexes) et suppose un certain nombre d’hypothèses, il démontre que les protocoles de sécurisation ne sont pas suffisamment intégrés avec les protocoles applicatifs tels qu’HTTP. Marsh décrit aussi dans son papier un scénario hypothétique où il serait possible d’obtenir des informations confidentielles sans que le client se connecte volontairement au site web objet de l’attaque.

Il existe encore un débat pour savoir si des utilisateurs de sites Web simples (donc sans authentification du client par un certificat) sont concernés, Marsh affirme que c’est bien le cas.

Très rapidement des propositions devraient être faites par l’IETF pour des modifications au protocole TLS et des mises à jour de GNU TLS et OpenSSL sont en cours de validation. Des annonces plus rapides que prévu sont donc à venir.