Malheureusement, le papier n'est pas très précis quant au fonctionnement exact de la faille, même si les diagrammes décrivant les échanges HTTPS et les captures réseau fournis aident pas mal. En fait, tout est tellement tourné vers HTTPS que ça rend un peu difficile l'évaluation de son impact dans d'autres contextes, comme un autre protocole sur SSL[1] ou des choses un peu différentes comme des négocations EAP. Pour autant, d'après ce que j'en comprends, HTTP semble particulièrement bien se prêter à l'exploitation en raison de spécifications vagues pour le traitement de cas très particuliers implicant une renégociation.

De manière plus générale, comme l'explique très bien Ivan Ristic, il s'agit d'un problème de protocole qui ne s'assure pas de la continuité et de la cohérence du contexte avant et après la renégociation. Dans le cas général, il semble que l'attaquant puisse, sous certaines conditions, injecter des données en début de session et rendre la main au client légitime. Pour HTTP en particulier, l'attaquant peut faire associer ses données à celle du client victime de l'attaque, ce qui ne manque pas de conduire à des résultats particulièrement intéressants. Typiquement l'injection d'une requête arbitraire qui viendra remplacer tout simplement celle du client légitime...

Il est cependant important de noter que cette attaque ne conduit pas à Man in the Middle cryptographique au sens de l'impact. L'attaquant ne se retrouve pas entre le client et le server à contrôler tout le trafic qu'ils échangent. Cette attaque utilise un MitM pour parvenir à une injection de données arbitraires, ce qui est tout de même assez différent. En particulier, s'il est capable d'injecter des données, l'attaquant n'en verra pas forcément les réponses. Mais ça reste une bien une maigre consolation qui ne vaut qu'au regard de ce qu'on en comprend à l'heure actuelle...

Les deux questions qu'on se pose immédiatement sont de savoir si on est vulnérable d'une part, et comme on corrige le tir d'autre part. Pour ce qui est des situations vulnérables, je pense qu'on peut résumer l'idée à toute configuration dans laquelle une renégociation est utilisée, voire tout simplement possible. Posé comme cela, ça n'avance cependant pas grand monde. Le papier nous aide à peine plus en nous disant que la plupart des installations web demandant une authentification par certificat seraient vulnérables, ainsi que toute installation autorisant le client à initier la renégociation, ce qui correspond aux trois scénarios d'exploitation décrits. On n'est cependant pas à l'abri d'un autre scénario, pourquoi pas applicable à un autre protocole que HTTP. Si vous voulez tester votre installation par vous même, vous pouvez recourir à l'outil proposé à cette fin par Mikhail Davidov ou utiliser le petit PoC posté jeudi soir sur Full Disclosure.

Côté solutions, il ne semble y avoir guère que l'interdiction des renégociations qui semble être efficace à l'heure actuelle. Le problème se situant au niveau du protocole, une solution parfaite va être longue à ratifier, sans parler de son déploiement effectif. Un patch pour OpenSSL a par contre été publié pour offrir un contournement le temps que tout soit corrigé en bonne et due forme. La version 0.9.8l intègre ce patch. Un correctif pour GNUTLS a également été proposé. Il est intéressant parce qu'il implémente la proposition de draft IETF visant justement à modifier le protocole pour corriger le problème[2]. Enfin, il semblerait qu'un WAF puisse aider à protéger le côté serveur, probablement même un NIDS, ce qui pourrait éventuellement rassurer ceux dont le site a vraiment besoin des renégociation... Ou pas...

Update : je vous conseille d'aller lire (et suivre) le billet de Thierry Zoller sur la question qui fournit et tient à jour une liste de pointeur vers les ressources adéquates (descriptions, patches, outils, advisories), ainsi que le document qu'il vient de mettre en ligne.

Ce n'est donc pas encore le Bigouane, la fin du commerce électronique, de l'Internet tel que nous le connaissons et tutti quanti. Surtout quand on considère que peu de sites ont le besoin impérieux de déclencher des renégociations TLS. Mais bon, on verra bien comment tout ça se décante...

Notes

[1] Genre IMAPS, POP3S, SMTPS, etc.

[2] En ajoutant un élément ("binding") dérivé du contexte cryptographique dans la renégociation pour assurer la continuité.