MITM

Une faille des protocoles SSL/TLS qui assurent notamment la sécurité des connexions vers les serveurs web (lorsque l’adresse est en https://) a été révélée hier. (click here if you want an automated translation to English)

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.