RC4 est-il encore sûr pour SSL/TLS ?

Michael Cobb, expert en sécurité applicative, détaille les implications de sécurité concrètes d’une faille récemment découverte dans l’algorithme de chiffrement RC4, pour les connexions HTTPS.

RC4 (Rivest Cipher 4), a été conçu par Ron Rivest de RSA, en 1987. Il est devenu l’algorithme de chiffrement de flux le plus utilisé en raison de sa rapidité et de sa simplicité. Il est exploité par des protocoles courants tels que WEP, pour la protection des réseaux WiFi, et SSL et TLS pour HTTPS. En fait, 50 % de tout le trafic TLS est actuellement protégé en utilisant l’algorithme RC4. Toutefois, des faiblesses ont été découvertes au fil des ans, indiquant que RC4 approche de sa fin de vie.

Une faille découverte récemment par Ban Bernstein, un professeur de l’université de l’Illinois, permet à un attaquant de recouvrer une quantité limitée de texte en clair en interceptant une connexion TLS utilisant le chiffrement RC4. L’attaque visant RC4 s’applique à toutes les versions de SSL et de TLS supportant cet algorithme. L’attaque visant RC4 est rendue possible par les failles statistiques du flux de clés généré par l’algorithme. Celui-ci révèle des parties des messages chiffrés, à condition que l’attaquant ait pu collecter suffisamment d’échantillons.

Cette faille ne représente pas une menace immédiate pour les utilisateurs de SSL/TLS : il s’agit d’une attaque multi-sessions pour l’heure difficile à mettre en oeuvre. L’attaquant doit être capable de capturer le trafic réseau entre client et serveur. Il est également nécessaire que le même texte chiffré soit envoyé à la même destination fixe dans un message, de manière répétée. Et même dans un tel scénario, l’attaquant ne serait capable que de recouvrer une petite partie du message.

Toutefois, les messages HTTP contiennent des entêtes codifiées, identiques tout au long de la conversation. Le contenu d’un cookie pourrait par exemple être capturé. L’une des plus grandes menaces consiste en un attaquant qui serait capable d’accéder aux données contenues dans un cookie. Par exemple, les cookies sont souvent utilisés pour stocker les information d’un compte utilisateur ou un ticket de session afin d’éviter aux utilisateurs de devoir s’identifier répétitivement. Si un pirate parvient à intercepter ces cookies, il peut se faire passer pour un utilisateur légitime et accéder à des données sensibles du site ou du service affecté.

Le protocole SSL/TLS supporte différents algorithmes de chiffrement. Mais la principaux navigateurs Web ne supportent pas les plus récents algorithmes. TLS 1.2 supporte les suites de chiffrement AEAD (Authenticated Encryption with Associated Data), mais cette version de TLS n’a pas encore été largement adoptée. La plupart des navigateurs, en dehors de Safari sur iOS, soit ne le supportent pas, soit ne le proposent pas par défaut. Une autre solution serait de changer la manière dont TLS utilise RC4, mais il faudrait faire cela sur chaque poste client et sur chaque serveur, et être capable de prendre en charge les futures améliorations de la méthode d’attaque de RC4.

Pour l’heure, les administrateurs peuvent déployer une implémentation de TLS 1.0 ou 1.1, chacune utilisant une suite de chiffrement CBC qui a été corrigée pour contrer les attaques BEAST et Lucky Thirteen. Ironiquement, ces attaques ont conduit de nombreux administrateurs à utiliser RC4 plutôt que CBC. Mais comme TLS est le protocole de chiffrement utilisé pour sécuriser le trafic Internet, son implémentation doit être parfaitement robuste et invulnérable aux attaques, y compris à celles qui sont les moins simples à mettre en oeuvre. Avec un peu de chance, cette toute nouvelle découverte provoquera un passage à une version plus sûre.

Adapté de l’anglais par la rédaction