MiTM sur SSL/TLS; faille protocolaire

La nouvelle est tombée il y a deux jours, il est possible de faire un MiTM sur du SSL/TLS. LEs journalistes d'internet vont encore parler de faille terrible, de big one, etc etc..
Oublions un peu les journaux du net et voyons plutôt les détails.

Tout d'abord, la source. L'article d'origine est situé sur le blog d'extended subset, qui contient les deux documents originaux les plus importants, le pdf schématique et l'article. Sur cette page, sont disponibles également des captures tcpdump.

Explication, de la faille, en deux temps. Tout d'abord, SSL est censé protéger contre tout type de MiTM, en intercalant entre le serveur et le client une couche de chiffrement . La couche SSL s'occupe donc des problématiques de chiffrement, échange de clés, etc... Entre autre problématique, celle de la renégociation des clés ou des méthodes de chiffrement. La faille se situe dans cette renégociation.
Ensuite, le SSL existe en deux méthodes, authentification serveur (ce qui est forcément le cas) et authentification côté client (ce qui est particulièrement rare). L'authent côté serveur permet au client d'authentifier le serveur ET de chiffrer les communications. L'authent côté client permet au serveur d'authentifier le client.
La couche applicative utilise ce tuyau authentifié et chiffré pour envoyer ses données.

Ceci étant posé, un MiTM reste possible ! La méthode exposée permet d'ajouter une quantité arbitraire de données en début de dialogue. Ce début de dialogue sera vu par le serveur non seulement comme légitime, mais en plus il sera authentifié!

Précisons les détails dans le cas d'une négociation HTTPs. Le schéma est celui-ci:
client --- MiTM --- serveur.
Le client envoie une requête au serveur. Le MiTM l'intercepte, puis négocie les clés de sessions entre le serveur et lui même. Il envoie une requête:
GET /secure/evil.html
X-swallow-this: <-- (sans retour chariot) Le MiTM redemande une négociation de clés, mais cette fois-ci, il route tous les paquets entre le client et le serveur. Le client imagine qu'il s'agit de la négo initiale des clés de sessions, de la méthode de chiffrement, etc et il envoie sa requête:

GET /secure/good.html
Host: thishost
Authent: authent-codes
Cookie: Cookies, etc..

Le serveur, lui concatène l'ensemble (puisque rien n'interdit la renégo en cours de dialogue applicatif) et voit donc la requête:

GET /secure/evil.html
X-swallow-this: GET /secure/good.html
Host: thishost
Authent: authent-codes
Cookie: Cookies, etc..

Ou l'on voit bien que la requête cliente est avalée dans l'entête X-swallow-this, mais que le reste des en-têtes du client (authent éventuelle, cookies, etc..) sont ajoutées. La requête est légitime, elle est chiffrée, et est donc effectuée par le serveur qui imagine dialoguer avec le client!
Eventuellement, le serveur demande le certificat client; du fait même du protocole, le serveur demande le certificat client _après_ la requête (les détails expliquant pourquoi sont dans le pdf.). La requête est authentifiée par le certificat client, et le serveur exécute aussi /secure/evil.html

SSL est donc entièrement battu: le SSL côté serveur est abusé, l'authent par login/pass est forwardée, et l'authent SSL cliente est elle aussi forwardée. Bien sûr, le MiTM ne voit pas la requête cliente (elle est chiffrée) ni la réponse du serveur (qui est chiffrée aussi). L'essentiel reste que l'attaquant, le MiTM, ait pu ajouter un entête choisi dans le dialogue SSL. La faille de sécurité est donc avérée. Il s'agit de plus d'une faille protocolaire puisque de bout en bout les normes ont été respectées.


Maintenant que ceci est posé, quels contremesures disposons nous?
1/ Interdire la renégociation SSL. Un patch pour openSSL est disponible. La question se pose alors: La renégociation lors d'un dialogue SSL est il 'mandatory' ? ou bien peut-on vivre sans? Si la renégo n'est pas nécessaire, alors c'est le meilleur moyen à court terme.

2/ Attendre une modification de la norme ce sur quoi l'IETF travaille actuellement. Puis attendre une modification des clients et serveurs.

3/ Pour les applis développées maison implémentant SSL, alors il faut également interdire la renégociation en cours de dialogue. Si une raison forte impose la renégociation des clés (comme la durée du dialogue ou le volume de données transférées) alors il faut casser la session applicative et en reprendre une nouvelle, ce qui peut être compliqué à mettre en oeuvre.

4/ Ajouter un firewall est complètement illusoire, même si cela reste des propositions qui sont faite comme j'ai pu lire sur internet :( (et là, sécurité FAIL, on connaît la chanson). Une faille protocolaire, au même titre que les canaux cachés, traversera aisément les firewalls puisque ces deux failles reposent sur un strict respect de la norme.

En conclusion, ce n'est pas le big one, mais un sérieux coup porté à la confiance apportée à SSL. Conclusion, si vous êtes un serveur, ne faites pas une confiance aveugle aux données clients pour la simple raison qu'elles sont chiffrées via SSL/TLS...

EDIT: 12/11/2009.
Le blog de sid en parle. Il contient plusieurs liens intéressants.

Chiffré ne signifie pas sécurisé.

La crypto est devenue part intégrante de la vie numérique.

Moi même, j'utilise des outils me permettant de chiffrer ou signer des mails à destination du monde entier, l'ensemble des clés se faisant confiance par le mécanisme des autorités de certification.

La crypto est toujours quelque chose de très aride à lire, comme par exemple la RFC 3852 qui spécifie la syntaxe des messages cryptos. On apprend que ces messages peuvent être signés, chiffrés, authentifiés ou que leur integrité soit assuré.
Mais le diable se niche dans les détails. Prenons l'exemple du chiffrement. Un fichier chiffré empêche quiconque de le lire, par définition.

Néanmoins, aucune garantie n'est faite sur son intégrité ou son authenticité!

Ce qui pose le problème suivant: imaginons qu'Alice veut écrire à Bob un message confidentiel.
Charlie peut tout à fait intercepter le message d'Alice et le supprimer. Puis envoyer un message chiffré avec la clé publique de Bob à Bob. Bob lira le message en pensant qu'il venait d'Alice. Il ne faut surtout pas qu'il imagine que le message soit d'Alice, bien que le message ait été parfaitement chiffré à l'aide de sa clé publique. La seule chose dont Bob soit sur, c'est que le message ne sera lu dorénavant que par lui, et qu'il a été lu par l'émetteur. Mais aucune garantie n'est faite sur l'émetteur.

Bien entendu, Charlie ne connaît pas le contenu du message d'Alice. Ce qui va poser des problèmes pratiques lors de la rédaction du second message pour Bob (Si Bob reçoit une proposition commerciale alors qu'Alice l'a prévenue qu'elle lui envoyait ses photos de vacances, il risque d'être soupçonneux.). Mais si Charlie connaît à peu près le contenu du message que doit envoyer Alice, alors il pourra le remplacer sans aucun problème.

Imaginons maintenant que Bob soit un client, et qu'il réalise un appel d'offre. Pour plus de confidentialité, il donne sa clé publique à Alice et Charlie pour qu'ils communiquent de manière sécurisée leurs propositions.
Charlie pourra usurper l'identité d'Alice sans aucun problème, afin de gagner à coup sûr l'appel d'offre. Il aura suffit à Charlie de connaître le type de mail qu'Alice envoie (ce qui est relativement faisable car l'appel d'offre est public, ainsi que le canevas de la réponse qu'Alice effectuera) et l'heure d'envoi. Et là, on voit bien que le chiffrement n'a amené absolument aucune sécurité contrairement a ce qu'imaginait Bob.

Les mêmes mécanismes d'usurpation peuvent être mis en oeuvre contre quelqu'un qui chiffre ses documents. Si j'ai accès au répertoire où ses documents sont chiffrés, et en m'aidant avec le nom des fichiers, je peux lui altérer grandement (sans qu'il s'en rende compte) ses fichiers.
Tout est chiffré, mais le fichier 'X' n'est plus le même. Si la personne est le DRH et que le fichier en question est mon contrat de travail, je devrais pouvoir le modifier de manière intéressante :-)

En conclusion, je dirais que chiffrer c'est bien, mais il ne faut pas se focaliser uniquement sur ce chiffrement.
Le chiffrement empêche un tiers de lire le contenu. Le chiffrement ne permet rien d'autre, ni à faire la moindre assertion sur l'émetteur, et encore moins sur l'intégrité des messages. Le chiffrement n'est donc qu'une étape, inutile, si elle est utilisée seule. Donc chiffrer, oui; mais signer est une obligation.

Certificats et \0

Lors de la blackhat, Moxie Marlinspike et Dan Kaminsky ont proposé un nouveau moyen pour abuser les clients effectuant des vérifications sur des certificats.

En effet, un client comme un navigateur web vérifie que le nom de domaine sur lequel il est connecté correspond bien au CN du certificat.

Il a été montré à la blackhat qu'il est possible de faire signer par des autorités des certificats s'appelant:
victime.com\x00un.autre.nom

Le client peut alors lire le CN comme "victime.com".
A l'époque, à peu près tous les navigateurs webs étaient victimes de cette attaque.
Firefox a depuis été patché.

Sur une mailing list a été posté un certificat (et sa clé privée, non protégée par mot de passe) particulièrement percutant puisque son sujet est
Subject: C=US, CN=*\x00thoughtcrime.noisebridge.net, ST=California, L=San Francisco, O=Noisebridge, OU=Moxie Marlinspike Fan Club
C'est à dire qu'il est wildcard donc valide pour tous les domaines! Ainsi, n'importe quel phisheur peut utiliser ce certificat pour faire passer son site web pour n'importe qui.

Sa mise en oeuvre est très simple (j'ai construit la maquette avec un serveur web apache sous linux en moins de 10mn) et je confirme qu'avec un Firefox 2.0.0 (non patché) la connexion se fait sans warning, sans aucun message:
Et les informations sont les suivantes:
Et les détails:


La connexion avec un firefox 3.5 signale bien l'erreur, tout comme firefox 3.0.14 présenté ici (le CN est affiché complet, avec le \00):
La sortie de ce certificat "wildcard" n'a pas fait tellement de vague.

Sur ces entrefaits, Moxie Marlinspike décide à son tour de produire un certificat contenant un caractère NUL contrefaisant un unique site, paypal:
www.paypal.com\x00unsite

De manière étrange, on lit des commentaires offusqués, par exemple de la part de Paypal (le compte Paypal de Moxie a d'ailleurs été suspendu :) ), et d'autres journaux en ligne, en voici un parmi tant d'autres http://www.theregister.co.uk/2009/10/06/paypal_banishes_ssl_hacker/.

Le traitement et la digestion de l'information par le web me surprendront toujours. Comment se fait il qu'une bombe comme ce certificat wildcard ne fasse pas parler de lui, alors que le certificat de paypal soit présenté comme une crise majeure? Un élément de réponse concerne l'utilisation des wildcards par IE et la microsoft API je pense, cf le papier de Marlinspike . Pour faire bref, seule la lib NSS utilisée par la suite Mozilla se fait abuser par un wildcard *. Internet Explorer lève une alerte tout de même.

EDIT:
A la réflexion, je pense que le point est précisément celui-ci. D'un côté, nous disposons d'un arme de phishing massive (la wildcard) mais qui ne touche qu'une famille de navigateur web qui est patchée depuis longtemps. J'ai d'ailleurs eu du mal à retrouver une ancienne version de firefox.
D'un autre côté, on a une faille massivement disponible (tout ce qui touche la crypto API de microsoft) mais dont la mise en oeuvre est compliquée, et coûte cher: il faut créer le certificat, générer la demande, payer pour se faire certifier par une autorité, etc.. Un certificat avec NUL devient subitement d'une grande valeur, même s'il ne vise au final que peu de monde