Firesheep

[galoupia]

Bonsoir
Pour info voilà ce que je viens de trouver.

http://www.01net.com/editorial/522840/f ... n-un-clic/

[Uther]

En effet, c'est un problème connu depuis bien longtemps. Espérons que ça décide les sites web à se mettent enfin au cryptage des données.

[vulcain]

Il y a un billet sur Linuxfr.org: http://linuxfr.org/2010/10/29/27514.html

Point intéressant le code: la certa dit:

Tout d’abord, il s’agit d’un outil non testé et au mode de développement inconnu. On ne reviendra pas ici sur les risques qu’il y a à installer de tels logiciels.

et dans l'article de Linuxfr, il y a un lien vers le code.
Si on voit le code on sait comment cela marche non ?

[teoli2003]

En fait, il n'y a rien de nouveau: n'importe qui pouvait faire cela avec Wireshark depuis des années (bien avant que Wireshark s'appelle Wireshark).

Il n'y a pas de miracle: si l'on utilise http avec un cookie de session, il est possible de hijacker la session si on écoute ce qui passe sur le réseau. Donc dès qu'on utilise un cookie pour identifier quelqu'un (et pas seulement l'authentification initiale), il faut passer en https.

Firesheep a le code ouvert et son contenu à été contrôlé: il n'y a pas de soucis avec l'extension elle-même. Tout site prétendant le contraire est à mettre dans la catégorie incompétent et à éviter.

En montrant le problème de manière à ce que n'importe qui puisse le vérifier, Firesheep, qui n'est pas un malware, gêne pas mal de sites web...

[calimo]

Firesheep a le code ouvert et son contenu à été contrôlé

Par qui ? Ici le code est tout petit, donc ça limite le risque, mais l'open source n'est pas une garantie contre la malveillance (et en plus, qui compile son extension soi-même à partir du code source ?)

Sinon, une alternative aux cookies, c'est l'authentification HTTP Digest. Il me semble que ce n'est pas vulnérable aux attaques de type rejeu (le cas des cookies).
Une question : est-ce que ce mode d'authentification est aussi vulnérable à ce type d'attaque par wifi ?

[teoli2003]

Firesheep a le code ouvert et son contenu à été contrôlé

Par qui ?

Par Mozilla, suite à une demande (refusée) de blacklist. Le code a *vraiment* été contrôlé (et c'est parce qu'il était court que cela a été possible; et regarder si les infos sont envoyées à l'extérieur dans un code non-obscurci, c'est pas la mer à boire, hein), maintenant on peut céder à la paranoïa en disant que le code compilé est différent, mais il a été vérifié qu'il ne se connecte pas à l'extérieur, donc c'est peu probable.

Cette extension est infiniment plus sûre que toutes les cochonneries ajoutées dans le navigateur par Google, Adobe, Apple, Microsoft ou des trucs comme CoolIris.

[teoli2003]

Sinon, une alternative aux cookies, c'est l'authentification HTTP Digest. Il me semble que ce n'est pas vulnérable aux attaques de type rejeu (le cas des cookies).
Une question : est-ce que ce mode d'authentification est aussi vulnérable à ce type d'attaque par wifi ?

Cela ne joue pas. Les cookies sont utilisés pour passer l'information d'authentification une fois que celle-ci a été faite (c'est nécessaire car le protocole HTTP est un protocole sans état, stateless en anglais). Le HTTP Digest ne sert qu'à l'authentification initiale; il serait impraticable de l'utiliser pour chaque requête, il faudrait entrer son mot de passe chaque fois que l'on clique sur un lien...

De plus le HTTP Digest est vulnérable à une attaque man-in-the-middle, ce qui n'est pas le cas de HTTPS + cleartext suivi de HTTPS + cookie.

Enfin, même si les messages cryptés sont courts et cela ne devrait pas être un problème hors d'un labo, le MD5 n'est plus considéré comme sûr de nos jours (quoique je doute qu'une attaque basée sur la faiblesse du MD5 permette de contourner le HTTP Digest. Je veux juste montrer par là qu'il n'est pas évolutif, contrairement au HTTPS qui peut supporter de nouvelles méthodes de cryptage et possède un système de versioning du protocole TLS utilisé).

[calimo]

Cela ne joue pas. Les cookies sont utilisés pour passer l'information d'authentification une fois que celle-ci a été faite (c'est nécessaire car le protocole HTTP est un protocole sans état, stateless en anglais). Le HTTP Digest ne sert qu'à l'authentification initiale; il serait impraticable de l'utiliser pour chaque requête, il faudrait entrer son mot de passe chaque fois que l'on clique sur un lien...

Non, le HTTP Digest n'est pas juste une authentification initiale. Les requêtes suivantes sont également authentifiées (dans un domaine spécifié, évidemment moins souple que les cookies tiers), et je me demande à quel point c'est résistant à un sniffing...
Par exemple, après s'être authentifié, sur une requête suivante Firefox envoie ça :

Code : Tout sélectionner

Authorization: Digest username="calimo", realm="Private access area", nonce="CATHsNWTBAA=75d08e55b1df6d3699f6dfce0b95d63790e09465", uri="/private/index.html", algorithm=MD5, response="1c7529a024a60492dcda2d2f95e8a686", qop=auth, nc=00000004, cnonce="1eed8d3e43cacaa9"

Ces valeurs changent à chaque requête successives (firefox renvoie un nouveau "nonce" pour la requête suivante), donc je pense que ce type d'authentification est résistant à l'attaque proposée ici.

Bien sûr rien n'empêche d'autres attaques, mais c'est quand-même plus compliqué de mettre en place un man in the middle (il faut être là à la connexion initiale, transmettre les requêtes de manière transparente, etc.).