URL: https://linuxfr.org/users/octane/journaux/la-fin-du-monde-est-une-fois-de-plus-pour-demain-ssl-crime Title: La fin du monde est (une fois de plus) pour demain : SSL crime Authors: octane Date: 2012年09月20日T16:06:38+02:00 Tags: Score: 43 Si vous n'habitez pas au fond de l'océan, il y a des chances que vous sachiez déjà ce qui va suivre. Demain, c'est la fin du monde car SSL, le dernier bastion de la sécurité sur internet (oui, c'est ironique) va sombrer corps et biens et disparaître dans un grand geyser catclysmique. Bref, si on redevient sérieux deux minutes, qu'est ce qui se passe demain? Deux chercheurs réputés, Juliana Rizzo et Thai Duong, bien connus pour avoir travaillé sur l'attaque [BEAST](http://en.wikipedia.org/wiki/BEAST_(computer_security)#TLS_1.0) annoncent une nouvelle attaque portant sur une spécificité de SSL combiné à la manière dont le protocole HTTP fonctionne. Etant donné leur renommée, beaucoup d'octets ont coulés dans les RJ45 et une hypothèse audacieuse, vraisemblablement celle qui sera exposée demain, a été proposé sur un site web: [http://zoompf.com/2012/09/explaining-the-crime-weakness-in-spdy-and-ssl](http://zoompf.com/2012/09/explaining-the-crime-weakness-in-spdy-and-ssl) La conf à lieu [là-bas](http://www.ekoparty.org/). Alors de quoi s'agit-il? ------------------------ ### Tout d'abord, un bref rappel sur la manière dont les données s'échangent en HTTP. Les échanges HTTP sont séparés en deux; tout d'abord on trouve les en-têtes, ensuite les données. Les en-têtes contiennent un certain nombre d'informations comme la date, la version du navigateur lorsqu'il s'agit d'une requête client, et la version du serveur lorsqu'il s'agit de la réponse, etc.. Les données, c'est le HTML bien connu, ainsi que pleins d'autres choses (images, sons, flash etc..) qui fait que le web est ce qu'il est aujourd'hui. Deux points vont nous intéresser particulièrement dans les en-têtes. Tout d'abord, il faut savoir que les en-têtes ne sont jamais compressés, au contraire du data qui peut l'être. Ensuite, un en-tête est très intéressant, il s'agit du champ "Cookie" qui permet (entre autre) d'authentifier un utilisateur. Ainsi, si vous surfez sur linuxfr en tant qu'anonyme, vous n'avez pas de cookie d'authent. Si vous vous êtes authentifié, alors un cookie permet au serveur de savoir qui vous êtes. Si quelqu'un vous vole votre cookie d'authent, alors il peut se faire passer pour vous, et écrire des journaux sous votre nom, vous connecter à votre messagerie, etc... Le vol du cookie d'authent permet de voler votre identité. Comme vous le savez sans doute, HTTP existe en version sécurisée, HTTPs qui a comme mérite de chiffrer les messages. Ainsi, un pirate écoutant vos connexions sur linuxfr ne pourra pas déchiffrer les en-têtes HTTP, et ne pourra pas lire le cookie d'authent, préservant ainsi votre identité. Et c'est ainsi sur tous vos sites webs important: banques, faceplook, gmail, poneyz.com, etc.. On comprend pourquoi les pirates tentent de voler ce Cookie, et pourquoi HTTPS permet de surfer l'esprit tranquille. Ceux qui surfent en clair peuvent s'attendre à voir [firesheep](http://en.wikipedia.org/wiki/Firesheep) utilisé contre eux, attaque automatisant le procédé de collecte de cookie. ### Un petit rappel sur SSL Les deux chercheurs cités ont découvert que certains sites proposent la compresion au niveau de SSL. Dans le cas d'HTTP, il n'y a pas beaucoup d'intérêt à le faire puisque la couche HTTP sait quoi compresser et comment le compresser. Mais l'option est là. Donc l'en-tête HTTP, précédemment non compressé, le devient grâce à la couche SSL. Et de fait, beaucoup de choses deviennent possible. On sait que le chiffrement ne modifie pas la taille des données. 1.5Mo à chiffrer vont faire 1.5Mo. La compression, elle, réduit les données. Si un attaquant parvient à ajouter des données dans un échange HTTP, alors le paquet chiffré devient plus gros, forcément. Mais si la couche SSL compresse avant de chiffrer, alors une propriété intéressante se profile. Imaginons un fichier contenant uniquement des 0. La compression est excellente, le chiffrement de la forme compressée aura donc une petite taille. Si j'ajoute à ce fichier d'autres zéros, alors la taille finale ne bougera pas. Si j'ajoute d'autres caractères, alors la taille compressée augmentera ainsi que celle du chiffré. Je constate donc que je récupère de l'information sur le fichier initial grâce à la seule information que le chiffré me donne: sa taille! Je peux donc déduire que le fichier initial contient beaucoup de zéros puisque en ajouter d'autres ne modifie que peu la taille du compressé chiffré! ### L'attaque L'idée consiste donc à envoyer plusieurs paquets au serveur en activant la compression **au niveau de SSL**. Le paquet normal est donc: GET /page.html HTTP/1.1 Host: victim.net Cookie: Monsupercookiedauthent Et l'attaquant va ajouter un second entête cookie: GET /page.html HTTP/1.1 Host: victim.net Cookie: Monsupercookiedauthent Cookie: A La couche de compression va donc constater une répétition de caractères: "Cookie: " et va donc les compresser, résultant en une certaine taille, puis le A qui ne se compresss pas. L'attaquant regarde la taille chiffrée, puis il réessaye avec Cookie: B. La taille résultante ne bouge pas. Puis avec C, etc.. Lorsqu'il arrive à "Cookie: M", alors la compression est meilleure, du fait d'une plus grande répétition de caractères! Et donc le chiffré est plus petit, et donc l'attaquant sait que le cookie démarre par un M. On itère sur le deuxième caractère, etc.. et l'attaquant découvre le Cookie! Phun and Profit! Note: les auteurs semblent dire qu'ils ont trouvé d'autres manières plus rapides que d'itérer char par char, mais l'idée derrière reste la même: comparer les chiffrés résultant. HTTPS est donc complètement défait et la seule solution aujourd'hui consiste à désactiver la compression SSL! ### Et dans la vraie vie? Cette attaque est très belle. Néanmoins, pas mal de zones d'ombres subsistent. - Comment envoyer pleins de requêtes au serveur? Il faut que la requête contienne le vrai cookie, ainsi que la ligne d'entête rajoutée. On entend parler de javascript, mais si javascript sait lire le cookie, pourquoi ne pas tout simplement l'envoyer à l'attaquant? Ce point n'est pas du tout clair. On lit aussi que l'attaquant peut fournir une page remplie de balise IMG, mais comment ajouter par la suite le faux Cookie? - Comment lire les paquets chiffrés? Apparemment, l'attaque prend comme acquis que l'attaquant est sur le routeur mais que ce n'est pas obligatoire. A la manière de firesheep, on peut imaginer que l'attaquant est dans un cybercafe et qu'il sniffe les réponses. - SSL n'est pas cassé, c'est SSL lorsqu'il protège les cookie d'authent HTTP et que la compression est possible. Stay tuned

AltStyle によって変換されたページ (->オリジナル) /