C'est un peu technique, je vais essayer de décrire en gros le principe de l'attaque.
Pour fixer le contexte, le problème concerne la partie symétrique du protocole, qui vient après la phase d'initialisation à base de crypto asymétrique; la phase asymétrique a permis d'établir un secret partagé qui permet de sécuriser des communications symétriques.
La couche de chiffrement (que ça soit de SSL, de TLS, de SSH...) prend des messages de taille raisonnable de la couche applicative et les traite afin de fournir deux garanties :
- secret du contenu (*)
- intégrité
(*) Le secret concerne la valeur de chaque octet du message, pas la longueur. SSL ne promet jamais de cacher la longueur d'un message. Ce n'est pas un objectif réaliste dans ce contexte. (Je devrais peut être développer ça ailleurs.)
Ces garanties sont symétriques, elles concernent les deux directions.
Chaque paquet de données à envoyer est donc chiffré avec une clé de chiffrement, et un code de détection d'erreur ("MAC") est utilisé pour l'intégrité. Ce code est basé sur un hachage cryptographique et une clé secrète par le procédé du HMAC.
Le contexte d'utilisation de SSL, comme de la plupart des chiffrements sur Internet, est basé sur l'hypothèse maximaliste d'un adversaire
- capable d'intercepter et de modifier tout message
- qui peut forcer n'importe quelle partie à envoyer en chiffré un message choisi
- qui peut mélanger un message choisi à des secrets
Par exemple, l'adversaire peut poliment demander à une partie d'envoyer M1 S1 M2 S2 M3 S3 ... à l'autre partie, où l'adversaire choisit M1 M2 ... et S1 S2 ... sont des secrets que l'adversaire veut découvrir.
Donc pour les couches supérieures, c'est très confortable; même un usage Web est possible, et le Web (*) est un des pires contextes de pour la sécurité : un site peut utiliser des éléments venant d'un autre site, ce qui rend la sémantique et les propriétés de sécurité d'un site Web assez "space".
(*) le Web c'est ce truc avec des navigateurs qui communiquent par HTTP, qui décodent le HTML, qui gèrent les IMG et les FORM, qui ont des FRAME et des IFRAME, qui gèrent les cookies HTTP, qui exécutent le JS, et qui permettent d'ouvrir plusieurs onglets simultanèment; ce n'est pas wget ou curl; ce n'est pas non plus SOAP.
Sur le Web, je peux demander à un client SSL (un navigateur) d'envoyer à un serveur TLS (un serveur Web Serv) ceci :
GET /M1 HTTP/1.1
Host: Serv
...
S1
Ce que contient M1 et qu'il existe réellement sur le serveur Web n'a aucune importance puisque la réponse n'a pas d'intérêt.
S1 est l'ensemble de en-têtes HTTP que l'adversaire n'est pas censé pouvoir deviner, notamment les cookies.
Remarquez que je peux demander autant de fois que je veux à un navigateur de faire ça, il suffit d'inclure des IMG sur un site tiers quelconque (sauf si l'utilisateur ne se connecte jamais à un site non sécurisé en même temps). Jamais le navigateur ne va afficher une alarme, et jamais il ne va activer de contre-mesures.
SSL est supposé être assez robuste pour gérer cela.