TLS : tout le monde en parle, pourquoi pas moi ?

À

moins que vous ne viviez en hermite au fond d'une grotte du Larzac profond, il y a peu de chance que vous ayez loupé la news de la semaine dernière : il y aurait une jolie possibilité d'exploitation de Man in the Middle affectant TLS v1.2 et d'autres versions antérieures, dont SSL v3. Le problème a été remonté sur la liste du groupe de travail TLS de l'IETF. Un article un poil plus détaillé de Marsh Ray et Steve Dispensa a été posté.

Il s'agirait d'une faille dans les renégociations de session TLS, qui vise à renouveler le contexte cryptographique d'une session en cours, laquelle peut être initiée aussi bien par le serveur que par le client. L'article propose trois scénarios d'exploitation visant des communications HTTPS qui permettent à un attaquant d'injecter des données arbitraires dans un flux TLS établi modulo le MitM. Pas glop, d'autant qu'une large majorité des implémentations sont touchées...

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 une proposition de draft IETF non publié 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...

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] Possiblement via une reprise (resumption) d'une partie du contexte cryptographique dans la renégociation pour assurer la continuité.